In a parent/child resource provider aggregate, if a child resource providers is deleted then the deleted child resource provider will be seen as available in the parent resource provider aggregate list.

Bug #1770570 reported by Dennis Ahuja
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Expired
Undecided
Unassigned

Bug Description

In a parent/child resource provider aggregate, if a child resource providers is deleted then the deleted child resource provider will be seen as available in the parent resource provider aggregate list.
For ex: create two resource providers having uuid's say A and B. Here, if B is attached to A then B is child to A.
Attach B as an aggregate to A using command "openstack --os-placement-api-version 1.1 resource provider aggregate set A --aggregate B"
Delete resource provider B using command " openstack resource provider delete B"
List aggregate resource provider for A "openstack resource provider aggregate list A"

There should be referential key constraint for <uuid> in "placement_aggregates" table for the resouce provider uuid in "resource_providers" table.

Tags: placement
Revision history for this message
Jay Pipes (jaypipes) wrote :

Hi Dennis, I believe you may be confusing aggregates with child relationships (nested providers).

When you create the resource provider, you can specify a parent provider UUID for that resource provider. This will make that resource provider a child of the provider you specified.

Aggregates, on the other hand, are simply groups of resource providers with no parent->child relationship.

When you create two resource providers, like so:

openstack resource provider create --name="rp_A"
openstack resource provider create --name="rp_B"

and then add those providers to an aggregate, like so:

openstack resource provider aggregate set <UUID of rp_A> --aggregate <UUID of aggregate_X>

you need to provider the UUID of the *aggregate*, not another resource provider. To put both resource providers in the same aggregate, you would do the same for rp_B:

openstack resource provider aggregate set <UUID of rp_B> --aggregate <UUID of aggregate_X>

at this point, both provider A and B are in aggregate X.

When deleting provider A, you would *not* delete provider B (because they are not related, just in the same aggregate).

To delete all providers in an aggregate, you would need to list the providers in the aggregate, like so:

openstack resource provider aggregate list <UUID of aggregate_X>

and call:

openstack resource provider delete <UUID of rp>

for each of the listed resource providers.

Now, that said, if what you are truly trying to represent is a parent->child relationship, then you would need to do the following [1]:

openstack resource provider create --name="parent"
openstack resource provider create --name="child" --parent-provider-uuid=<UUID of parent>

At that point, if you attempt to delete the parent, you will get an error back about not being able to delete a parent until its children are first deleted. There is a foreign key constraint on the resource_providers table that prevents orphaning records in this way.

Best,

-jay

[1] Unfortunately, this functionality in the openstack client is still under review here: https://review.openstack.org/#/c/546675/ at the time of this comment, so please be patient as we bring the client up to date with the latest placement service API.

tags: added: placement
Chris Dent (cdent)
Changed in nova:
status: New → Incomplete
Revision history for this message
Dennis Ahuja (dennis.ahuja) wrote :

Hello, I just use the term parent child to make the problem easily understandable.
I tried the solution provided by Jay pipes but its not working for me as I don't understand what to use for "UUID of aggregate_X" (how to create a separate aggregate X to add rp_A and rp_B to it).

Changed in nova:
status: Incomplete → New
Revision history for this message
Tetsuro Nakamura (tetsuro0907) wrote :

I _think_ Dennis is saying that in the last command of “openstack resource provider aggregate list <rpA_uuid>” the uuid shouldn’t come up because <rpB_uuid> is already deleted.
But the command “openstack resource provider aggregate set <rpA_uuid> --aggregate <agg_uuid>” expects *aggregate uuid* for its argument of —aggregate. Note that it is not *resource provider uuid*.
If there is no such specified aggregate uuid, the placement server creates it. So actually here the placement internally creates a new aggregate uuid record that is the same string as rpB_uuid, but as a totally different one; “rpB_uuid” is *resource provider* uuid, but what it creates is *aggregate* uuid. So what users are expected here is to use a totally new aggregate uuid for the “—aggregate” argument.

You can generate a totally new aggregate uuid to create using any tools.
$ python
>>> import uuid
>>> uuid.uuid4()
UUID('b5f53c57-8888-4912-86b3-e1fe53b1de19')

I agree that what confuses us here is that there is no such CLI command support for something like “openstack resource provider aggregate create”.
This is because we don’t have the REST API for aggregate creation. This maybe worth reporting as a request for enhancement.
1. Should we have a CLI in osc-placement to create just a uuid locally for the convenience? - “openstack resource provider aggregate uuid create”…this sounds to me an incomplete work around, though.
2. Should we add a new REST API in server side something like `POST /aggregates/<agg_name>` and let aggregates have names for the convenience? - “openstack resource provider aggregate create <agg_name>”
3. Any ideas?

Anyway does it answer the question, Dennis?

Revision history for this message
Chris Dent (cdent) wrote :

Making this as incomplete so we can encourage some more input from Dennis. Dennis, can you comment on Tetsuro's description and questions please?

Changed in nova:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.]

Changed in nova:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.