Open Stack

On 03/17/2014 03:46 PM, Salvatore Orlando 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.

Just some thoughts on this before you go and change the way it works :)

We've played with the admin state setting enough to think that more than two
states - True and False, could be useful.  For example, having an "UP and
accepting new routers", "UP but NOT accepting new routers", and "DOWN" seems to
be something useful for operators.  Whether those values are set via one flag or
two doesn't matter - perhaps one for UP/DOWN, the other to give the scheduler
hints is more useful?

That would allow an admin to say, set a limit on the number of resources
(routers/networks) on a network node, and take it out of rotation when the limit
is hit.

> 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.
> Hence, the reaction to putting a resource administratively down should that its
> operational status goes down as well, and therefore there is no need for an
> explicit operational status "ADMIN DOWN".
> This is, from what I can gather, what already happens with ports.
> The bug [1] is, in a way, an example of the above situation, since no action is
> taken upon an object , in this case a network, being put administratively down.
> 
> 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? 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've (unfortunately?) used it many times, for example during a High-Availability
event you might want to un-manage all the routers on a network node and have
them re-scheduled elsewhere.

Thanks,

-Brian

> 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
> <mailto: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
>     <mailto:mestery at noironetworks.com>> wrote:
> 
>         On Mon, Mar 17, 2014 at 8:36 AM, Eugene Nikanorov
>         <enikanorov at mirantis.com <mailto: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
>             <mailto: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 <mailto: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 <mailto: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
>