Open Stack

Yup, I'm cool with that, too.

Best,
-jay

On 03/16/2017 11:00 AM, Sylvain Bauza wrote:
>
>
> 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
>>
>
> __________________________________________________________________________
> 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
>