On 10/02/2014 01:47 PM, Jay Pipes 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...
Sorry, I misread your statement to mean that there should be only a
single state field rather than a comment on the type of the variable.
The telecom administrative state values are "locked", "unlocked", and
"shutting down", so it seems unlikely that they would be the impetus for
the Neutron values.
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.
:)
Chris
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
