<div dir="ltr"><div>After this discussion I'm thinking about not adding comprehensive handling for provider removing case at all.<br></div><div>Probably we'll need to document desired workflow and postpone cleanup feature until use cases are more clear.</div>
<div><br></div><div>I like the idea of leaving resource in ERROR state. </div><div>However, If we're not implementing updating pool with provider (reassociating with another provider), such resources will be unusable until provider is reenabled.</div>
<div><br></div><div>I suggest the following workflow for provider removal:</div><div>1) Admin removes provider from config and restarts neutron</div><div>2) Neutron changes state of all related resources to ERROR and removes associations </div>
<div>(so we can't just go back and readd provider to conf file)</div><div>3) Users are given ability to associate resource with existing provider</div><div>Still this leaves ability to operate on unassociated resources. IMO that's ok, and can be easily handled with noop driver (this is hidden from user, user thinks he works with logical resource without backend implementation).</div>
<div><br></div><div>From lbaas API change perspective, such workflow results in:</div><div>1) adding 'provider' attribute to 'pools' resource. Users can only provide it on pool creation</div><div>2) adding special member action 'associate_provider' that can only be run on non-associated pools</div>
<div class="gmail_extra"><br>What do you think?</div><div class="gmail_extra"><br></div><div class="gmail_extra">P.S. going back to noop driver role: it's a basic complimentary part of plugin API that must be called.</div>
<div class="gmail_extra">So either noop or other driver must be called when user performs any operation on resource.</div><div class="gmail_extra"><br><br></div></div>