>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 <jaypi...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev