<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 11:46 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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">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>Yep, READY seems fine to me as well.</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><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></blockquote><div>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)</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><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?</div>
</div></blockquote><div>Quite radical solution, what would be the alternative?</div><div>I'd be glad just to improve the names and set of operational status constants.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div> 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div>I think it will be used often at least in lbaas world. <br>
</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API-ItemTypes.html</a></div>

<div><br></div></div><div class="HOEnZb"><div class="h5"><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><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>
<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><div><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><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"><div><br></div></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><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" 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></div>