feature: maas resource pool support

How do resource pools typically work in production? Is this typically used to pool resources such as storage nodes or ceph targets? Using this as a model-config I worry is too wide a default. The docs on resource-pools doesn't seem to really speak to which level.

rharding,

Loosely speaking, resource pools are similar to OpenStack projects the way I see it. And those were originally introduced for multi-tenancy and resource pooling associated with that (in addition to identity and RBAC).

You would use them to separate nodes that different people use for different purposes.

For example:

1) resource pool 1: nodes in DC pods [0, 2] - Cloud Region 1;
2) resource pool 2: nodes in DC pods [3, 5] - Cloud Region 2;
3) resource pool 3: John Doe's NUC playground.

You may have a different set of availability zones for each resource pool but not necessarily (similar to how network spaces may span fabrics - those are just different concepts).

One additional note: in case of OpenStack and projects Juju has to use different cloudspecs to actually provision machines in different projects.

With MAAS this is not the case - the API endpoint and credentials are the same, just the view of nodes on which to operate on is different.

Thanks this is helpful. As you noted projects are a different cloud typically and so we want to make sure we're looking to model the resource pools correctly across Juju ideas. Given your examples 1,2,3 it would seem that they might work more like regions, but I thought we already did a form of regions in MAAS so we'll have to investigate some more.

I think it's important to distinguish them from regions as regions of a cloud are roughly sets of endpoints providing independent control planes (and data planes in most cases).

For example, in OpenStack, every endpoint in a catalog has a region_id foreign key and the same Keystone catalog can be used to store endpoints of multiple control planes backed by separate databases and message queues. Region ID acts as a multiplexor for endpoints when specified in client connection parameters.

mysql> select id, region_id, url from endpoint;
# ...
| 048cd95ba5b84e51a9f79d8b15e9edea | RegionOne | http://openstack.local:80/swift|
| 05ea110348d44efe8ce8e9668309e00f | RegionOne | http://openstack.local:8774/v2/$(tenant_id)s|
| 08695cb91c1a4915a6a4b797ec9607f2 | RegionOne | http://openstack.local:8774/v2/$(tenant_id)s
# ...

In contrast, resource pools provide a way to logically group nodes within a single control plane without any MAAS API isolation.

If we modeled them as part of Credentials then they would already be model
wide. However, I'd want to be sure that you wouldn't want to use 2
different pools for 2 different applications in the same model.
With CMR we can be a little bit more restrictive as you *could* create a
second model for the applications that you want. However, it still means
you wouldn't see them in the same fashion for "juju status", etc.

Constraints have the nice property that you *can* set model constraints
which will be the default for all applications in the model that don't
explicitly override them.

I'm not sure what the concern is around applying them to existing
deployments as you can always change constraints on an app or model.
They've always had the property that they only affect new allocations.

John
=:->

On Tue, Sep 18, 2018, 11:10 Dmitrii Shcherbakov <email address hidden>
wrote:

> I think it's important to distinguish them from regions as regions of a
> cloud are roughly sets of endpoints providing independent control planes
> (and data planes in most cases).
>
> For example, in OpenStack, every endpoint in a catalog has a region_id
> foreign key and the same Keystone catalog can be used to store endpoints
> of multiple control planes backed by separate databases and message
> queues. Region ID acts as a multiplexor for endpoints when specified in
> client connection parameters.
>
> mysql> select id, region_id, url from endpoint;
> # ...
> | 048cd95ba5b84e51a9f79d8b15e9edea | RegionOne |
> http://openstack.local:80/swift|
> | 05ea110348d44efe8ce8e9668309e00f | RegionOne |
> http://openstack.local:8774/v2/$(tenant_id)s|
> | 08695cb91c1a4915a6a4b797ec9607f2 | RegionOne |
> http://openstack.local:8774/v2/$(tenant_id)s
> # ...
>
> In contrast, resource pools provide a way to logically group nodes
> within a single control plane without any MAAS API isolation.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1792943
>
> Title:
> feature: maas resource pool support
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1792943/+subscriptions
>

jameinel,

I overlooked the fact that constraints can be changed via `juju set-model-constraints #...` and `juju set-constraints <appname> #...` at a post-deployment stage.

https://docs.jujucharms.com/2.4/en/charms-constraints#setting-displaying-and-updating-constraints-for-an-application

So making a constraint on a certain pool and later updating it if needed seems reasonable.

We've just hit the need for this feature :-

We have been modifying FCE to deploy for a customer who wishes just to use KVM pods, but the customer requires that some of these KVM machines be constrained to different machines.

E.g.

Kubernetes master unit 0 does not run on the same KVM host as unit 1.

Thanks, we've got it in the roadmap ideas list and will see if we can get some movement on it in the future.

Update: we now have two customers with which we are in active deployment and for which we'll need to do additional workarounds due to this juju gap. We will bring this up in the roadmap planning sprint to be addressed please.