Open Stack

On 05/29/2016 06:19 PM, Chris Dent wrote:
> This gets a bit complex (to me) but: The idea for step 4 is that the
> resource tracker will be modified such that:
>
> * if the compute node being claimed by an instance is a member of some
>    aggregates
> * and one of those  aggregates is associated with a resource provider
 > * and the resource provider has inventory of resource class DISK_GB

Kinda. What the compute node needs is an InventoryList object containing 
all inventory records for all resource classes both local to it as well 
as associated to it via any aggregate-resource-pool mapping.

The SQL for generating this InventoryList is the following:

SELECT
   i.resource_provider_id,
   i.resource_class_id,
   i.total,
   i.reserved,
   i.min_unit,
   i.max_unit,
   i.step_size,
   i.allocation_ratio
FROM inventories AS i
  INNER JOIN resource_providers AS rp
   ON i.resource_provider_id = rp.id
WHERE rp.uuid = 'compute-node-1'
OR rp.id IN (
   SELECT rpa1.resource_provider_id
   FROM resource_provider_aggregates rpa1
     INNER JOIN resource_provider_aggregates rpa2
      ON rpa1.aggregate_id = rpa2.aggregate_id
     INNER JOIN resource_providers rp
      ON rpa2.resource_provider_id = rp.id
   WHERE rp.uuid = 'compute-node-1'
);

> then rather than claiming disk on the compute node, claim it on the
> resource provider.

Yes.

> The first hurdle to overcome when doing this is to trace the path
> from compute node, through aggregates, to a resource provider. We
> can get a list of aggregates by host, and then we can use those
> aggregates to get a list of resource providers by joining across
> ResourceProviderAggregates, and we can join further to get just
> those ResourceProviders which have Inventory of resource class
> DISK_GB.
>
> The issue here is that the result is a list. As far as I can tell
> we can end up with >1 ResourceProviders providing DISK_GB for this
> host because it is possible for a host to be in more than one
> aggregate and it is necessary for an aggregate to be able to associate
> with more than one resource provider.

Well, yes, it *is* possible in the future to have >1 resource pool for 
shared storage attached to an aggregate. However, the thinking for this 
first round of code was that currently compute nodes either have local 
disk or they use a (single per availability zone) shared storage 
solution for the VM's ephemeral disks.

So, for deployers that use a shared storage solution, they will need to 
create a resource pool via:

  `openstack resource-pool create`

associate that resource pool with a single aggregate (and create that 
aggregate if it does not already exist) that is associated with ALL 
compute nodes. The compute nodes in these deployments will have *no 
corresponding inventory record for DISK_GB*.

For deployers who use local disk on each compute node, no action is needed.

We can deal with multiple shared storage pools per aggregate at a later 
time. Just take the first resource provider in the list of inventory 
records returned from the above SQL query that corresponds to the 
DISK_GB resource class and that is resource provider you will deduct from.

> If the above is true and we can find two resource providers providing
> DISK_GB how does:
>
> * the resource tracker know where (to which provider) to write its
>    disk claim?
> * the scheduler (the next step in the work items) make choices and
>    declarations amongst providers? (Yes, place on that node, but use
> disk provider
>    X, not Y)

Assume only a single resource provider of DISK_GB. It will be either a 
compute node's resource provider ID or a resource pool's resource 
provider ID.

> If the above is not true, why is it not true? (show me the code
> please)
>
> If the above is an issue, but we'd like to prevent it, how do we fix it?
> Do we need to make it so that when we associate an aggregate with a
> resource provider we check to see that it is not already associated with
> some other provider of the same resource class? This would be a
> troubling approach because as things currently stand we can add Inventory
> of any class and aggregates to a provider at any time and the amount of
> checking that would need to happen is at least bi-directional if not multi
> and that level of complexity is not a great direction to be going.

For this initial work, my idea was to have some code that, on creation 
of a resource pool and its association with an aggregate, if that 
resource pool has an inventory record with resource_class of DISK_GB 
then remove any inventory records with DISK_GB resource class for any 
compute node's (local) resource provider ID associated with that 
aggregate. This way we ensure the existing behaviour that a compute node 
either has local disk or it uses shared storage, but not both.

Best,
-jay

> So, yeah, if someone could help me tease this out, that would be
> great, thanks.
>
>
> [1]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html#work-items
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>