<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 17, 2014, at 3:46 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><div dir="ltr">It is a common practice to have both an operational and an administrative status.<div>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".</div>
<div>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.</div></div></blockquote><div><br></div>PCM: I like READY!</div><div><br><br><blockquote type="cite"><div dir="ltr">
<div><br></div><div>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.</div>
<div>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".</div><div>
This is, from what I can gather, what already happens with ports.</div><div>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.<br>
</div><div><br></div><div>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?</div></div></blockquote><div><br></div>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.</div><div><br></div><div>I wouldn't have heartburn in removing admin control, but then again, I'm not familiar with how network operations would use this stuff.</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr">
<div>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!</div><div>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.</div></div></blockquote><div><br></div>PCM: It clearly is something commonly seen in the hardware router/switch world (at least at Cisco :).</div><div><br></div><div><br></div><div><div><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>PCM (Paul Michali)</div><div><br></div><div>MAIL <a href="mailto:pcm@cisco.com">pcm@cisco.com</a></div><div>IRC pcm_ (<a href="http://irc.freenode.net">irc.freenode.net</a>)</div><div>TW @pmichali</div><div>GPG key 4525ECC253E31A83</div><div>Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83</div></div></span></div><br><div></div></div><div><br><blockquote type="cite"><div dir="ltr">
<div><br></div><div>Thanks in advance for reading through my ramblings!</div><div>Salvatore</div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/neutron/+bug/1237807">https://bugs.launchpad.net/neutron/+bug/1237807</a></div>
<div>[2] Please bear in mind that my opinion is wrong in most cases, or at least is different from that of the majority!</div><div>[3] <a href="https://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html">https://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html</a></div>
<div>[4] <a href="http://archives.opennebula.org/documentation:archives:rel2.0:api">http://archives.opennebula.org/documentation:archives:rel2.0:api</a></div><div>[5] <a href="http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API-ItemTypes.html">http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API-ItemTypes.html</a></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 March 2014 17:16, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><div>> <span style="font-family:arial,sans-serif;font-size:13px">Seems awkward to me, if an IPSec connection has a status of ACTIVE, but an admin state of ADMIN DOWN.</span></div>
</div><div><span style="font-family:arial,sans-serif;font-size:13px">Right, you see, that's the problem. Constant name 'ACTIVE' makes you expect that IPSec connection should work, while it is a deployment status.</span></div>
<div class="">
<div><br></div><div>> <span style="font-size:13px;font-family:arial,sans-serif">OK, so the change is merely change "ACTIVE" into "DEPLOYED" instead?</span></div></div><div>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.<span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div><br></div><div>Thanks,</div><div>Eugene.</div><div> </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 7:31 PM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Mon, Mar 17, 2014 at 8:36 AM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Kyle,<div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br></div></blockquote></div>
<div>It's a typical use case for network devices to have both admin and operational</div>
<div>state. In the case of having admin_state=DOWN and operational_state=ACTIVE,</div><div>this just means the port/link is active but has been configured down. Isn't this</div><div>the same for LBaaS here? Even reading the bug, the user has clearly configured</div>
<div>the VIP pool as admin_state=DOWN. When it becomes ACTIVE, it's due to this</div><div>configuration that the pool remains admin_state=DOWN.</div><div><br></div><div>Am I missing something here?</div></div></div></div>
</blockquote></div><div>No, you're not. The user sees 'ACTIVE' status and think it contradicts 'DOWN' admin_state. </div><div>It's naming (UX problem), in my opinion.</div><div><br></div></div></div>
</div></blockquote></div><div>OK, so the change is merely change "ACTIVE" into "DEPLOYED" instead?</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Thanks,</div>
<div>Eugene.</div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>