Open Stack

Le 16/03/2017 14:12, Chris Dent a écrit :
> 
> (This message is a question asking "should we fix this?" and "if so,
> I guess that needs spec, since it is a microversion change, but
> would an update to the existing spec be good enough?")
> 
> We have a small wart in the API for creating and updating resources
> classes [1] that only became clear while evaluating the API for
> resource traits [2]. The interface for creating a resource class is
> not particularly idempotent and as a result the code for doing so
> from nova-compute [3] is not as simple as it could be.
> 
> It's all in the name _get_of_create_resource_class. There is at
> least one but sometimes two HTTP requests: first a GET to
> /resource_classes/{class} then a POST with a body to
> /resource_classes.
> 
> If instead there was just a straight PUT to
> /resource_classes/{class} with no body that returned success either
> upon create or "yeah it's already there" then it would always be one
> request and the above code could be simplified. This is how we've
> ended up defining things for traits [2].
> 


We recently decided to not ship a specific client project for tricks
like that, and we preferred to have a better REST API quite well documented.

Given that consensus, I think I'm totally fine using the PUT verb
instead of GET+POST and just verify the HTTP return code.


> Making this change would also allow us to address the fact that
> right now the PUT to /resource_classes/{class} takes a body which is
> the _new_ name with which to replace the name of the resource class
> identified by {class}.  This is an operation I'm pretty sure we
> don't want to do (commonly) as it means that anywhere that custom
> resource class was used in an inventory it's now going to have this
> new name (the relationship at the HTTP and outer layers is by name,
> but at the database level by id, the PUT does a row update) but the
> outside world is not savvy to this change.
> 

Agreed as well.

-Sylvain

> Thoughts?
> 
> [1]
> http://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/custom-resource-classes.html#rest-api-impact
> 
> [2]
> http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/resource-provider-traits.html#rest-api-impact
> 
> [3]
> https://github.com/openstack/nova/blob/d02c0aa7ba0e37fb61d9fe2b683835f28f528623/nova/scheduler/client/report.py#L704
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>