Open Stack

On Mar 17, 2014, at 3: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.

PCM: I like READY!


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

PCM: The only thing I could think of, with VPN, is maybe an operator wanting to bring down all IPSec connections maybe for some maintenance action. It would be much easier to do an admin down on the service, do whatever is needed, and then do an admin up, rather than deleting all the IPSec connections and then recreating them.

I wouldn't have heartburn in removing admin control, but then again, I'm not familiar with how network operations would use this stuff.


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

PCM: It clearly is something commonly seen in the hardware router/switch world (at least at Cisco :).


PCM (Paul Michali)

MAIL          pcm at cisco.com
IRC            pcm_  (irc.freenode.net)
TW            @pmichali
GPG key    4525ECC253E31A83
Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83


> 
> 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/20140317/0c1ac9b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/0c1ac9b2/attachment.pgp>