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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
