Eugene, Won't we need that mixing anyway? If there is an admin down state, shouldn't that drive the status to down? Seems awkward to me, if an IPSec connection has a status of ACTIVE, but an admin state of ADMIN DOWN. Or were you thinking of something different?
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 On Mar 17, 2014, at 10:32 AM, Eugene Nikanorov <enikano...@mirantis.com> wrote: > 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
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
