[RFE] Nova API doesn't return aggregate's uuid, which is needed when using the placement API

Bug #1652642 reported by Miguel Lavalle
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Wishlist
Jay Pipes

Bug Description

When creating an aggregate using the Nova API, it doesn't return the new aggregate's uuid:

DEBUG (connectionpool:400) http://192.168.33.12:8774 "POST /v2.1/os-aggregates HTTP/1.1" 200 179
DEBUG (session:371) RESP: [200] Content-Length: 179 Content-Type: application/json Openstack-Api-Version: compute 2.37 X-Openstack-Nova-Api-Version: 2.37 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id: req-90906f19-0f69-46d0-bb33-134eb962421a Date: Mon, 26 Dec 2016 16:04:16 GMT Connection: keep-alive
RESP BODY: {"aggregate": {"name": "test-aggregate", "availability_zone": null, "deleted": false, "created_at": "2016-12-26T16:04:16.077923", "updated_at": null, "deleted_at": null, "id": 3}}

This becomes a problem when the aggregate is intended to be associated with a resource provider through the placement API, which requires the aggregate's uuid:

(Pdb) my_client.aggregates.associate('29f69c38-57b8-45b4-a9d4-287faeab74d7', ['3'])
*** BadRequest: {"errors": [{"status": 400, "request_id": "req-3e5a0b16-67f5-41b5-8f90-997cb88db31e", "detail": "The server could not comply with the request since it is either malformed or otherwise incorrect.\n\n JSON does not validate: u'3' is not a 'uuid' Failed validating 'format' in schema['items']: {'format': 'uuid', 'type': 'string'} On instance[0]: u'3' ", "title": "Bad Request"}]} (HTTP 400) (Request-ID: req-3e5a0b16-67f5-41b5-8f90-997cb88db31e)

I am testing this with a 4 nodes devstack built with Nova and Neutron master branches

Tags: api
Revision history for this message
Miguel Lavalle (minsel) wrote :

IMO, the fix for this has to consider the following:

1) When creating an aggregate, the Nova API has to return the uuid assigned to it in the response
2) In the placement API, GET /resource_providers/{uuid}/aggregates returns the list of uuid's associated with the resource provider (http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/generic-resource-pools.html#get-resource-providers-uuid-aggregates). As a consequence, at a minimum, when doing a GET /os-aggregates (Nova API), the response must include an uuid attribute for each aggregate listed. This will enable the user to translate the aggregates uuids in the placement API to the ids used by the aggregate operations (GET /os-aggregates/{aggregate_id}, PUT /os-aggregates/{aggregate_id}, DELETE /os-aggregates/{aggregate_id}) in the Nova API.

- Ideally, the GET /os-aggregates/{aggregate_id}, PUT /os-aggregates/{aggregate_id} and DELETE /os-aggregates/{aggregate_id} in the Nova API will also accept uuids (i.e. GET /os-aggregates/{aggregate_uuid}, PUT /os-aggregates/{aggregate_uuid} and DELETE /os-aggregates/{aggregate_uuid}). But this is a nice to have, not essential, as long as Nova's GET /os-aggregates return the uuids

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

Setting to critical since without this, we have no way of determining the UUID of aggregates to associate via the placement API...

Changed in nova:
importance: Undecided → Medium
importance: Medium → Critical
assignee: nobody → Jay Pipes (jaypipes)
status: New → Confirmed
status: Confirmed → Triaged
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/415031

Changed in nova:
status: Triaged → In Progress
Revision history for this message
Matt Riedemann (mriedem) wrote : Re: Nova API doesn't return aggregate's uuid, which is needed when using the placement API

This is a REST API impacting change and a new microversion so we're going to need a blueprint and a spec for it.

tags: added: api
Changed in nova:
assignee: Jay Pipes (jaypipes) → Matt Riedemann (mriedem)
Matt Riedemann (mriedem)
Changed in nova:
assignee: Matt Riedemann (mriedem) → Jay Pipes (jaypipes)
importance: Critical → High
Revision history for this message
Matt Riedemann (mriedem) wrote :
Changed in nova:
assignee: Jay Pipes (jaypipes) → Matt Riedemann (mriedem)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/415031
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=03c2776e49e12ff7f877480a041626a654533f27
Submitter: Jenkins
Branch: master

commit 03c2776e49e12ff7f877480a041626a654533f27
Author: Jay Pipes <email address hidden>
Date: Mon Dec 26 17:58:44 2016 -0500

    Return uuid attribute for aggregates

    Adds a Compute API microversion that triggers returning an aggregate's UUID
    field. This field is necessary for scripts that must populate the placement API
    with resource provider to aggregate relationships, which rely on UUIDs for
    global identification.

    APIImpact
    blueprint: return-uuid-from-os-aggregates-api
    Change-Id: I4112ccd508eb85403933fec8b52efd468e866772
    Closes-bug: #1652642

Changed in nova:
status: In Progress → Fix Released
Revision history for this message
Miguel Lavalle (minsel) wrote : Re: Nova API doesn't return aggregate's uuid, which is needed when using the placement API

Jay, Matt and the rest of the Nova team,

Thank you very much from the Neutron team for the quick fixing of this. Highly appreciated

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 15.0.0.0b3

This issue was fixed in the openstack/nova 15.0.0.0b3 development milestone.

Matt Riedemann (mriedem)
Changed in nova:
assignee: Matt Riedemann (mriedem) → Jay Pipes (jaypipes)
summary: - Nova API doesn't return aggregate's uuid, which is needed when using the
- placement API
+ [RFE] Nova API doesn't return aggregate's uuid, which is needed when
+ using the placement API
Changed in nova:
importance: High → Wishlist
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.