<div dir="ltr">Hi folks,<div><br></div><div>We've been discussing a patch that fixes <a href="https://bugs.launchpad.net/neutron/+bug/1242351">https://bugs.launchpad.net/neutron/+bug/1242351</a> </div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>IMO, admin_state_up (kind of confusing attribute too) and state are two different independent </div>
<div>attributes that could have any value and in most cases should not affect each other, for example:</div><div><br></div><div>1) Configuration is UP, but not deployed, e.g. state = PENDING_CREATE</div><div>2) Configuration is DOWN, but deployed, state = ACTIVE</div>
<div>Case #2 is clearly confusing, but that just because of the name 'ACTIVE', which should probably better changed to 'DEPLOYED'</div><div><br></div><div>My proposal is the following:<br></div><div>1) admin_state_up and status are two independent attributes.</div>
<div>admin_state_up turns on/off the configuration, status is for information only: PENDING_CREATE/DELETE, DEPLOYED, ERROR.</div><div>I'm not sure we need INACTIVE here.</div><div>2) We document this behavior. We can't just rename ACTIVE to DEPLOYED because it's a bw-incompatible API change.</div>
<div>3) We deprecate ACTIVE constant in favor of DEPLOYED</div><div><br></div><div>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) </div>
<div>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</div><div><br></div><div>Please share your feedback. </div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div>