Open Stack

On Mon, Mar 17, 2014 at 11:46 PM, Salvatore Orlando <sorlando at nicira.com>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 <enikanorov at mirantis.com> 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 <mestery at noironetworks.com>wrote:
>>
>>> On Mon, Mar 17, 2014 at 8:36 AM, Eugene Nikanorov <
>>> enikanorov at mirantis.com> 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
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140318/7e79bc72/attachment.html>