On Mon, Mar 17, 2014 at 7:26 AM, Eugene Nikanorov <[email protected]>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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
