Open Stack

On Mar 17, 2014, at 8:26 AM, Eugene Nikanorov <enikanorov at 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          pcm at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/0e992871/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/0e992871/attachment.pgp>