[openstack-dev] [api] Re: [Neutron][L3] Stop agent scheduling without topping sevices

Everett Toews everett.toews at RACKSPACE.COM
Wed Jan 21 22:04:23 UTC 2015

On Jan 9, 2015, at 8:15 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> Adding [api] topic.
> On 01/08/2015 07:47 PM, Kevin Benton wrote:
>> Is there another openstack service that allows this so we can make the
>> API consistent between the two when this change is made?
> Kevin, thank you VERY much for asking the above question and caring about consistency in the APIs!
> There was a discussion on the ML about this very area of the APIs, and how there is current inconsistency to resolve:
> http://openstack-dev.openstack.narkive.com/UbM1J7dH/horizon-all-status-vs-state
> You were involved in that thread, so I know you're very familiar with the problem domain :)
> In the above thread, I mentioned that this really was something that the API WG should tackle, and this here ML thread should be a catalyst for getting that done.
> What we need is a patch proposed to the openstack/api-wg that proposes some guidelines around the REST API structure for "disabling some resource for administrative purposes", with some content that discusses the semantic differences between "state" and "status", and makes recommendations on the naming of resource attributes that indicate an admnistrative state.
> Of course, this doesn't really address Jack M's question about whether there should be a separate "mode" (in Jack's terms) to indicate that some resource can be only manually assigned and not automatically assigned. Personally, I don't feel there is a need for another mode. I think if something has been administratively disabled, that an administrator should still be able to manually alter that thing.
> All the best,
> -jay

I did some preliminary analysis of the current design on state vs status.


So far it doesn’t get into the semantics but identifies which services use state and/or status and counts up how many calls use such a param.

Please feel free to add to the analysis.


More information about the OpenStack-dev mailing list