Open Stack

On Mon, Mar 17, 2014 at 7: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.
>
> 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.
>
> 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'
>
> It's a typical use case for network devices to have both admin and
operational
state. In the case of having admin_state=DOWN and operational_state=ACTIVE,
this just means the port/link is active but has been configured down. Isn't
this
the same for LBaaS here? Even reading the bug, the user has clearly
configured
the VIP pool as admin_state=DOWN. When it becomes ACTIVE, it's due to this
configuration that the pool remains admin_state=DOWN.

Am I missing something here?

Thanks,
Kyle


> 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.
> 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
>
> There is one serious consequence of the proposal above: real backends
> should support turning configurations on and off. 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
>
> 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/94e2d176/attachment.html>