Open Stack

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 <pcm at cisco.com> wrote:

>
>
> 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
>
>
>
> _______________________________________________
> 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/fffc4e0e/attachment.html>