Hi Paul, Thanks for the reply.
IMO, a disadvantage of having UP/DOWN/ADMIN DOWN values for status is that we mix admin_state and status. That will require us to implement non-trivial logic of state-status transitions. It also has to be carefully documented to avoid user confusion like in all those bugs. Thanks, Eugene. On Mon, Mar 17, 2014 at 5:38 PM, Paul Michali <p...@cisco.com> wrote: > > > On Mar 17, 2014, at 8:26 AM, Eugene Nikanorov <enikano...@mirantis.com> > wrote: > > Hi folks, > > We've been discussing a patch that fixes > https://bugs.launchpad.net/neutron/+bug/1242351 > 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. > > > PCM: I'm currently working similar issues on VPN... > > https://bugs.launchpad.net/neutron/+bug/1291619 > https://bugs.launchpad.net/neutron/+bug/1291609 > > And there is an existing bug that is a subset of the second one I created: > > https://bugs.launchpad.net/neutron/+bug/1228005 > > > > 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. > > > PCM: For the Cisco plugin, I was working on the following (to stay within > the confines of existing definitions)... > > - If service ADMIN DOWN -> service and all connections are moved to DOWN > state. > - 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). > - If connection fails to create -> connection status = ERROR, and use DOWN > for service, if only one connection. > > > 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. > > IMO, admin_state_up (kind of confusing attribute too) and state are two > different independent > attributes that could have any value and in most cases should not affect > each other, for example: > > 1) Configuration is UP, but not deployed, e.g. state = PENDING_CREATE > 2) Configuration is DOWN, but deployed, state = ACTIVE > Case #2 is clearly confusing, but that just because of the name 'ACTIVE', > which should probably better changed to 'DEPLOYED' > > > 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. > > 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. > > > > My proposal is the following: > 1) admin_state_up and status are two independent attributes. > admin_state_up turns on/off the configuration, status is for information > only: PENDING_CREATE/DELETE, DEPLOYED, ERROR. > I'm not sure we need INACTIVE here. > > > 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. > > 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. > > > 2) We document this behavior. We can't just rename ACTIVE to DEPLOYED > because it's a bw-incompatible API change. > > > 3) We deprecate ACTIVE constant in favor of DEPLOYED > > > PCM: I like UP better that DEPLOYED, only because a created VPN service is > not fully deployed. > > > > There is one serious consequence of the proposal above: real backends > should support turning configurations on and off. > > > 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. > > > Otherwise we could only implement admin_state_up change with > deploy/undeploy (or status attribute will not make sense for particular > driver) > 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 > > > 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. > > 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. > > Regards, > > Regards, > > PCM (Paul Michali) > > MAIL p...@cisco.com > IRC pcm_ (irc.freenode.net) > TW @pmichali > GPG key 4525ECC253E31A83 > Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 > > > Please share your feedback. > > Thanks, > Eugene. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
