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".

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, 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.

Chris

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to