<div dir="ltr">Hi Paul,<div><br></div><div>Thanks for the reply.</div><div><br></div><div>IMO, a disadvantage of having UP/DOWN/ADMIN DOWN values for status is that we mix admin_state and status.</div><div>That will require us to implement non-trivial logic of state-status transitions.</div>
<div>It also has to be carefully documented to avoid user confusion like in all those bugs.</div><div><br></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 5:38 PM, Paul Michali <span dir="ltr"><<a href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class=""><div><br></div><div><br></div><div>On Mar 17, 2014, at 8:26 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:</div>
</div><div><div><div class=""><br><blockquote type="cite"><div dir="ltr">Hi folks,<div><br></div><div>We've been discussing a patch that fixes <a href="https://bugs.launchpad.net/neutron/+bug/1242351" target="_blank">https://bugs.launchpad.net/neutron/+bug/1242351</a> </div>
<div>and came to a conclusion that what we have right now as an operational status ("status" attribute of the resource) may be confusing for a user.</div></div></blockquote><div><br></div></div>PCM: I'm currently working similar issues on VPN…</div>
<div><div><br></div><div><a href="https://bugs.launchpad.net/neutron/+bug/1291619" target="_blank">https://bugs.launchpad.net/neutron/+bug/1291619</a></div><div><a href="https://bugs.launchpad.net/neutron/+bug/1291609" target="_blank">https://bugs.launchpad.net/neutron/+bug/1291609</a></div>
<div><br></div><div>And there is an existing bug that is a subset of the second one I created:</div><div><br></div><div><a href="https://bugs.launchpad.net/neutron/+bug/1228005" target="_blank">https://bugs.launchpad.net/neutron/+bug/1228005</a></div>
<div class=""><div><br></div><div><br></div><blockquote type="cite"><div dir="ltr">
<div><br></div><div>This attribute is used to show deployment status and readiness of the configuration. For some reason we have 'ACTIVE' constant in the range of possible constants for 'status' attribute and that creates wrong expectation for users. Users think that if status is ACTIVE then configuration should work, but ACTIVE just means that it has been successfully deployed.</div>
<div><br></div></div></blockquote><div><br></div></div>PCM: For the Cisco plugin, I was working on the following (to stay within the confines of existing definitions)…<div><br></div><div>- If service ADMIN DOWN -> service and all connections are moved to DOWN state.</div>
<div>- If service ADMIN UP -> If one connection, then service state = connection state. If > 1 connection, service ACTIVE (could later check all conns and set service ACTIVE if at least one is ACTIVE).</div><div>- If connection fails to create -> connection status = ERROR, and use DOWN for service, if only one connection.</div>
<div class=""><div><br></div><div><div><br></div></div><blockquote type="cite"><div dir="ltr"><div>I've seen bugs/questions for other advanced services that expose the same user confusion as the bug that I've mentioned. I also saw same patches that try to fix that.</div>
<div><br></div><div>IMO, admin_state_up (kind of confusing attribute too) and state are two different independent </div>
<div>attributes that could have any value and in most cases should not affect each other, for example:</div><div><br></div><div>1) Configuration is UP, but not deployed, e.g. state = PENDING_CREATE</div><div>2) Configuration is DOWN, but deployed, state = ACTIVE</div>
<div>Case #2 is clearly confusing, but that just because of the name 'ACTIVE', which should probably better changed to 'DEPLOYED'</div></div></blockquote><div><br></div></div>PCM: I agree that ACTIVE is misleading. I'm not sure DEPLOYED is much clearer for VPNaaS, but not sure of a better alternative. Having created a service is only part of the VPN deployment, one needs a connection created as well. The service just binds VPN to a router.<div>
<br></div><div><div>I do think that a new status of ADMIN DOWN is a good definition of a service or connection that has admin_state_up=False. It indicates that the user does not want the connections to be on-line at this time.</div>
<div><br></div></div><div class=""><div><br></div><blockquote type="cite"><div dir="ltr"><div><br></div><div>My proposal is the following:<br></div><div>1) admin_state_up and status are two independent attributes.</div>
<div>admin_state_up turns on/off the configuration, status is for information only: PENDING_CREATE/DELETE, DEPLOYED, ERROR.</div><div>I'm not sure we need INACTIVE here.</div></div></blockquote><div><br></div></div>PCM: I guess I'd like to see one status for VPN service with the values: PENDING CREATE/DELETE, UP, ERROR, ADMIN DOWN, DOWN. I could see the same thing for IPSec connections for the service.</div>
<div><br></div><div>The ADMIN DOWN indicates that there is not an operational issue, but an administrative action holding the service down. Not sure how this maps to other services.</div><div><br></div><div><div class="">
<br><blockquote type="cite"><div dir="ltr"><div>2) We document this behavior. We can't just rename ACTIVE to DEPLOYED because it's a bw-incompatible API change.</div></div></blockquote><div><br></div><blockquote type="cite">
<div dir="ltr">
<div>3) We deprecate ACTIVE constant in favor of DEPLOYED</div></div></blockquote><div><br></div></div>PCM: I like UP better that DEPLOYED, only because a created VPN service is not fully deployed.</div><div><br></div><div>
<div class=""><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>There is one serious consequence of the proposal above: real backends should support turning configurations on and off. </div></div></blockquote>
<div><br></div></div>PCM: Yeah, I've put a request in for the Cisco VPN device driver to support admin up/down from the REST API (device has the ability already, but not in the REST API). I'm currently maintaining some state in the driver as a temporary work-around to track when the connection is admin down - as it is deleted on the device.</div>
<div><br></div><div><br></div><div><div class=""><blockquote type="cite"><div dir="ltr"><div>Otherwise we could only implement admin_state_up change with deploy/undeploy (or status attribute will not make sense for particular driver) </div>
<div>Deploy/undeploy might be simple to implement is an overkill from performance stand point. Need to do wiring, communicate with backend to redeploy whole config, etc</div></div></blockquote><div><br></div></div>PCM: I currently have the device driver deleting the IPSec connection, when ADMIN DOWN, but once REST API is in place, the device will just set the state to down and it can easily be set ADMIN UP.</div>
<div><br></div><div>This is a timely subject (thanks for bringing it up), as I'm trying to figure out how to deal with admin up/down with reference VPN implementation and need to quickly figure that out.</div><div><br>
</div><div>Regards,</div><div><br></div><div><div>Regards,</div><div><br></div><div><div><span style="border-collapse:separate;border-spacing:0px"><div style="word-wrap:break-word"><div>PCM (Paul Michali)</div><div><br></div>
<div>MAIL <a href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a></div><div>IRC pcm_ (<a href="http://irc.freenode.net" target="_blank">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><blockquote type="cite"><div class=""><div dir="ltr"><div><br></div><div>
Please share your feedback. </div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div></div><div class="">
_______________________________________________<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>
</div></blockquote></div><br></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>