On Jan 9, 2015, at 8:15 AM, Jay Pipes <jaypi...@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.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to