Open Stack

After this discussion I'm thinking about not adding comprehensive handling
for provider removing case at all.
Probably we'll need to document desired workflow and postpone cleanup
feature until use cases are more clear.

I like the idea of leaving resource in ERROR state.
However, If we're not implementing updating pool with provider
(reassociating with another provider), such resources will be unusable
until provider is reenabled.

I suggest the following workflow for provider removal:
1) Admin removes provider from config and restarts neutron
2) Neutron changes state of all related resources to ERROR and removes
associations
(so we can't just go back and readd provider to conf file)
3) Users are given ability to associate resource with existing provider
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).

>From lbaas API change perspective, such workflow results in:
1) adding 'provider' attribute to 'pools' resource. Users can only provide
it on pool creation
2) adding special member action 'associate_provider' that can only be run
on non-associated pools

What do you think?

P.S. going back to noop driver role: it's a basic complimentary part of
plugin API that must be called.
So either noop or other driver must be called when user performs any
operation on resource.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130731/a3fa76e7/attachment.html>