Open Stack

Replies inline,
Salvatore


On 17 March 2014 21:38, Eugene Nikanorov <enikanorov at mirantis.com> wrote:

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

The interval between RC1 and the summit is the right time to be radical!
The idea came to me after looking at bug 1237807 where putting
administratively down a network raises question on what actions should be
taken for the ports on that network.
So I thought it might make more sense just to waive admin status for a
network. And then I thought why not just waive that attribute for all
resources?


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

There is no doubt that it can be used. Even for ports, you can use it as a
short way to block a port which is generating suspicious traffic.
The question is whether it's something that is actually used in practice
when it comes to IaaS use cases. Knowing very little from the user
perspective, I then looked at the other APIs for inspiration. By the way,
even GCE does not have this concept:
https://developers.google.com/compute/docs/reference/latest/

>
> 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
>>
>>
>
> _______________________________________________
> 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/20140317/c8308077/attachment.html>