Open Stack

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'

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/cfe2a72b/attachment.html>