Open Stack

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