Open Stack

>In other words, all our APIs would look like the Neutron API as it exists
today.

That's a bad comparison because the Neutron API doesn't have a standard
that it follows at all. If there was a standard for states/statuses that
Neutron was following for all of the objects, the status of the Neutron API
today would be in a much less annoying state.

On Thu, Oct 2, 2014 at 12:47 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 10/02/2014 03:14 PM, Chris Friesen wrote:
>
>> On 10/01/2014 12:37 PM, Jay Pipes wrote:
>>
>>  IMO, the term "state" should be the only one used in the OpenStack APIs
>>> to refer to the condition of some thing at a point in time. The term
>>> "state" can and should be prefaced with a refining descriptor such
>>> "task" or "power" to denote the *thing* that the state represents a
>>> condition for.
>>>
>>> One direct change I would make would be that Neutron's "admin_state_up"
>>> field would be instead "admin_state" with values of UP, DOWN (and maybe
>>> UNKNOWN?) instead of having the *same* GET /networks/{network_id} call
>>> return *both* a boolean "admin_state_up" field *and* a "status" field
>>> with a string value like "ACTIVE". :(
>>>
>>
>> Hi Jay,
>>
>> I wonder if this would tie into our other discussion about
>> distinguishing between the "desired state" vs the "actual state".
>> Conceivably you could have the "admin state" be UP, but a fault has
>> resulted in an "actual state" other than "ACTIVE".
>>
>
> My comment above was about the inconsistency of how things are named and
> the data types representing them. There is a status field of type string,
> and an admin_state_up field of type boolean, both in the same response. Why
> wasn't it called admin_state and made a string field to follow the
> convention of the status field? I'm guessing it probably has to do with the
> telecom IT recommendations you cite below...
>
>  As a reference point, CCITT X.731 goes into huge detail about state and
>> status.  They define three orthogonal types of state (operational,
>> usage, and administrative), and many types of status (availability,
>> alarm, control, etc.)  I'm not suggesting that OpenStack should use
>> those exact terms
>>
>
> The very last thing I believe OpenStack should use as a reference is
> anything the telecommunications IT industry has put together as a
> recommendation.
>
> If we do use telecom IT as a guide, we'll be in a worse state (pun
> intended), ease-of-use and user-friendliness-wise, than we already are, and
> literally every API will just be a collection of random three and four
> letter acronyms with nobody other than a veteran network engineer
> understanding how anything works.
>
> In other words, all our APIs would look like the Neutron API as it exists
> today.
>
> >, but it suggests that some people have found it useful
>
>> to have state along multiple axes rather than trying to stuff everything
>> into a single variable.
>>
>
> I'm not opposed to using multiple fields to indicate state; I thought I
> was pretty clear about that in my initial response?
>
> Best,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141002/78cf9c75/attachment.html>