You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Placement API was introduced to OpenStack in the Newton release.
It allows administrative users to request and modify data about resource providers, inventory records, allocation records and grouping of providers (aggregates).
While the Placement API is currently a directory within the nova source tree, it is an entirely independent service from the OpenStack Compute API. It has its own service endpoint in the Keystone catalog and has its own REST API microversion history.
It would be great to add support to gophercloud for the placement API service.
I'm eager to contribute this if cores give me the go-ahead.
I'm eager to contribute this if cores give me the go-ahead.
Sure - go for it :)
For entire feature sets such as this, we like to break things up into per-method PRs. Picking something arbitrary from the link you gave, each of these would be a separate PR.
You can bundle them up into a single Issue like how it was done in #287.
Usually the first PR, GET, will be the largest since it'll include a lot of boilerplate code and the resource's resulting structure. You can "chain" branches/PRs together since the next branch/PR will naturally use code from the previous. If you submit PRs this way, prefix the title such as:
Placement: GET traits
[pending #above] Placement: PUT traits
This can cause a rebase chain if a parent PR needed changes. It's admittedly a nuisance, but it does help keep things small.
Let me know if you have any questions or need any help.
@jaypipes Quick question: You mentioned the word "aggregates". Does the Placement API modify the functionality of the os-aggregates API calls?
I was just about to open an issue to add os-aggregates functionality and wanted to know if there will be some overlap. No doubt os-aggregates will still be applicable for pre-placement environments, but future behavior will be good to note.
@jtopjian Placement aggregates and Nova host aggregates are different concepts, actually. Both concepts will remain in each API for the foreseeable future. If you'd like to create an issue about os-aggregates and assign to me, go for it. :)
@jtopjian Some of the differences between Nova host aggregates and Placement aggregates include:
Nova host aggregates can have metadata associated with them (this is actually how availability zones are "implemented" in Nova). Placement aggregates are ONLY groupings of resource providers [1], nothing more.
A Nova host aggregate is actually NOT associated with a compute node (the thing that provides compute resources). Nova host aggregates are actually tied to a nova-computeservice daemon. The significance of this is that Nova host aggregates are not applicable to Ironic compute nodes, because a single nova-compute service daemon controls many Ironic compute nodes. It's not possible to say "Ironic compute node A and B are associated with Nova host aggregate X if Ironic compute node A and B are associated with different nova-compute service daemons.
[1] A resource provider can be a compute node, a volume group, an IP pool, pretty much anything.
Activity
jtopjian commentedon Sep 24, 2017
Sure - go for it :)
For entire feature sets such as this, we like to break things up into per-method PRs. Picking something arbitrary from the link you gave, each of these would be a separate PR.
You can bundle them up into a single Issue like how it was done in #287.
Usually the first PR, GET, will be the largest since it'll include a lot of boilerplate code and the resource's resulting structure. You can "chain" branches/PRs together since the next branch/PR will naturally use code from the previous. If you submit PRs this way, prefix the title such as:
This can cause a rebase chain if a parent PR needed changes. It's admittedly a nuisance, but it does help keep things small.
Let me know if you have any questions or need any help.
jtopjian commentedon Sep 29, 2017
@jaypipes Quick question: You mentioned the word "aggregates". Does the Placement API modify the functionality of the os-aggregates API calls?
I was just about to open an issue to add
os-aggregatesfunctionality and wanted to know if there will be some overlap. No doubtos-aggregateswill still be applicable for pre-placement environments, but future behavior will be good to note.jaypipes commentedon Sep 29, 2017
@jtopjian Placement aggregates and Nova host aggregates are different concepts, actually. Both concepts will remain in each API for the foreseeable future. If you'd like to create an issue about os-aggregates and assign to me, go for it. :)
jaypipes commentedon Sep 29, 2017
@jtopjian Some of the differences between Nova host aggregates and Placement aggregates include:
Nova host aggregates can have metadata associated with them (this is actually how availability zones are "implemented" in Nova). Placement aggregates are ONLY groupings of resource providers [1], nothing more.
A Nova host aggregate is actually NOT associated with a compute node (the thing that provides compute resources). Nova host aggregates are actually tied to a
nova-computeservice daemon. The significance of this is that Nova host aggregates are not applicable to Ironic compute nodes, because a singlenova-computeservice daemon controls many Ironic compute nodes. It's not possible to say "Ironic compute node A and B are associated with Nova host aggregate X if Ironic compute node A and B are associated with different nova-compute service daemons.[1] A resource provider can be a compute node, a volume group, an IP pool, pretty much anything.
jtopjian commentedon Sep 29, 2017
@jaypipes Got it. Thank you!
ildarsv commentedon Dec 22, 2017
@jaypipes @jtopjian Hello! Do you know, does anybody work on Nova host aggregates stuff? If not, let me do it, I'll create a separate issue.
jaypipes commentedon Dec 22, 2017
ildarsv commentedon Dec 31, 2017
Hi, np, os-aggregates support was merged!
#691
dkt26111 commentedon Jan 10, 2020
Since there hasn't been any activity on this for 2 years, I will create a PR to add the first placement APIs.
Manila: add share acl resource (gophercloud#526)
pierreprinetti commentedon Oct 29, 2021
@dkt26111
Thank you for your work on the placement API.
Do you think there is more work required to complete a basic coverage of the API?
Add ParentProviderUUID to resourceProvider
Add Delete to placement resourceproviders
Add Get to placement resource providers
Add Get to placement resourceproviders
75 remaining items
Implement Placement allocations POST
Implement Placement usages
Implement Placement usages
Implement Placement usages
Implement Placement usages
Add Placement resourceprovider list post 1.39
Add Placement resourceprovider list post 1.39
Add Placement resourceprovider list post 1.39
Add Placement resourceprovider list post 1.39
Implement Placement allocations GET
Implement Placement allocations PUT
Implement Placement allocations DELETE
Implement Placement allocations POST
Implement Placement usages
Add Placement resourceprovider list post 1.39