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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
