Re: [openstack-dev] [nova] [placement] small wart in the resource class API
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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [placement] small wart in the resource class API
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] [placement] small wart in the resource class API
(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].
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.
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
--
Chris Dent ¯\_(ツ)_/¯ https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
