Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the Placement API #526

Open
jaypipes opened this issue Sep 24, 2017 · 10 comments
Open

Support the Placement API #526

jaypipes opened this issue Sep 24, 2017 · 10 comments

Comments

@jaypipes
Copy link

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.

@jtopjian
Copy link
Contributor

jtopjian commented Sep 24, 2017

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.

@jtopjian
Copy link
Contributor

@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.

@jaypipes
Copy link
Author

@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
Copy link
Author

@jtopjian Some of the differences between Nova host aggregates and Placement aggregates include:

  1. 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.

  2. 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-compute service 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.

@jtopjian
Copy link
Contributor

@jaypipes Got it. Thank you!

@ildarsv
Copy link
Contributor

ildarsv commented 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
Copy link
Author

jaypipes commented Dec 22, 2017 via email

@ildarsv
Copy link
Contributor

ildarsv commented Dec 31, 2017

Hi, np, os-aggregates support was merged!
#691

@dkt26111
Copy link
Contributor

Since there hasn't been any activity on this for 2 years, I will create a PR to add the first placement APIs.

cardoe pushed a commit to cardoe/gophercloud that referenced this issue Aug 27, 2020
* Manila: add share resource

* Manila: comment out the shrink test

* Manila: minor code review changes

* Manila: add detailed error handling

* Manila: add share_access resource (ACL)

* Manila: minor code review and acl import support

* Manila: add share access detailed error handling
@pierreprinetti
Copy link
Contributor

@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?

nikParasyr added a commit to nikParasyr/gophercloud that referenced this issue Feb 23, 2022
Add ParentProviderUUID to placement/v1/resourceproviders createOpts.
Moreover restructure acceptance tests for consistency and for future
additions.

[Docs](https://docs.openstack.org/api-ref/placement/?expanded=create-resource-provider-detail)

Relates to: gophercloud#526
nikParasyr added a commit to nikParasyr/gophercloud that referenced this issue Mar 18, 2022
Add ParentProviderUUID to placement/v1/resourceproviders createOpts.
Moreover restructure acceptance tests for consistency and for future
additions.

[Docs](https://docs.openstack.org/api-ref/placement/?expanded=create-resource-provider-detail)

Relates to: gophercloud#526
mdelord pushed a commit to ovh/gophercloud that referenced this issue Oct 7, 2022
Add ParentProviderUUID to placement/v1/resourceproviders createOpts.
Moreover restructure acceptance tests for consistency and for future
additions.

[Docs](https://docs.openstack.org/api-ref/placement/?expanded=create-resource-provider-detail)

Relates to: gophercloud#526
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants