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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
