On Mon, Mar 17, 2014 at 11:46 PM, Salvatore Orlando <[email protected]>wrote:
> It is a common practice to have both an operational and an administrative > status. > I agree ACTIVE as a term might result confusing. Even in the case of a > port, it is not really clear whether it means "READY" or "LINK UP". > Terminology-wise I would suggest "READY" rather than "DEPLOYED", as it is > a term which makes sense for all resources, whereas the latter is probably > a bit more suitable for high layer services. > Yep, READY seems fine to me as well. > > In my opinion [2] putting a resource administratively down mean the user > is deliberately deciding to disable that resource, and this goes beyond > simply "disabling its configuration", as mentioned in an earlier post. For > instance, when a port is put administratively down, I'd expect it to not > forward traffic anymore; similarly for a VIP. > Agree. But it worth mentioning that disabling a resource doesn't mean removing it from the backend, which, in turn, requires the backend and their drivers to support switching configuration off (or otherwise that kind of behavior becomes backend-dependent and that creates what is called 'uneven API experience) > > However, since this is that time of the release cycle when we can use the > mailing list to throw random ideas... what about doing an API change were > we decide to put the administrative status on its way to deprecation? > Quite radical solution, what would be the alternative? I'd be glad just to improve the names and set of operational status constants. While it's a common practice in network engineering to have an admin > status, do we have a compelling use case for Neutron? > I'm asking because 'admin_state_up' is probably the only attribute I've > never updated on any resource since when I started using Quantum! > I think it will be used often at least in lbaas world. Thanks, Eugene. Also, other IaaS network APIs that I am aware of ([3],[4],[5]) do not have > such concept; with the exception of [3] for the virtual router, if I'm not > wrong. > > Thanks in advance for reading through my ramblings! > Salvatore > > [1] https://bugs.launchpad.net/neutron/+bug/1237807 > [2] Please bear in mind that my opinion is wrong in most cases, or at > least is different from that of the majority! > [3] https://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html > [4] http://archives.opennebula.org/documentation:archives:rel2.0:api > [5] > http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API-ItemTypes.html > > > > On 17 March 2014 17:16, Eugene Nikanorov <[email protected]> wrote: > >> > Seems awkward to me, if an IPSec connection has a status of ACTIVE, >> but an admin state of ADMIN DOWN. >> Right, you see, that's the problem. Constant name 'ACTIVE' makes you >> expect that IPSec connection should work, while it is a deployment status. >> >> > OK, so the change is merely change "ACTIVE" into "DEPLOYED" instead? >> We can't just rename the ACTIVE to DEPLOYED, and may be the latter is not >> the best name, but yes, that's the intent. >> >> Thanks, >> Eugene. >> >> >> >> On Mon, Mar 17, 2014 at 7:31 PM, Kyle Mestery >> <[email protected]>wrote: >> >>> On Mon, Mar 17, 2014 at 8:36 AM, Eugene Nikanorov < >>> [email protected]> wrote: >>> >>>> Hi Kyle, >>>> >>>> >>>> >>>> >>>> >>>> >>>>>> It's a typical use case for network devices to have both admin and >>>>> operational >>>>> state. In the case of having admin_state=DOWN and >>>>> operational_state=ACTIVE, >>>>> this just means the port/link is active but has been configured down. >>>>> Isn't this >>>>> the same for LBaaS here? Even reading the bug, the user has clearly >>>>> configured >>>>> the VIP pool as admin_state=DOWN. When it becomes ACTIVE, it's due to >>>>> this >>>>> configuration that the pool remains admin_state=DOWN. >>>>> >>>>> Am I missing something here? >>>>> >>>> No, you're not. The user sees 'ACTIVE' status and think it contradicts >>>> 'DOWN' admin_state. >>>> It's naming (UX problem), in my opinion. >>>> >>>> OK, so the change is merely change "ACTIVE" into "DEPLOYED" instead? >>> >>> >>>> Thanks, >>>> Eugene. >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
