Repository navigation
Support the Placement API #526
Description
Activity
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 traitsThis 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-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.@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.
-
- On 12/22/2017 06:21 AM, Ildar Svetlov wrote: @jaypipes <https://github.com/jaypipes> @jtopjian <https://github.com/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.Apologies, Ildar, I have not yet had any time to do this. :( If you have time, please do feel free to take it on. Best, -jay
Since there hasn't been any activity on this for 2 years, I will create a PR to add the first placement APIs.
- added a commit that references this issue
on Aug 27, 2020 @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?
75 remaining items
- added 3 commits that reference this issue
on Apr 14, 2026 - added 2 commits that reference this issue
on May 4, 2026 - added 6 commits that reference this issue
on Jun 18, 2026
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
gophercloudfor the placement API service.I'm eager to contribute this if cores give me the go-ahead.