Open Stack

Hi folks,

Recently we've been discussing with Nachi Ueno some specific use case of
deployments with multiple providers for particular advanced service.

What If admin wants to remove certain provider from configuration file?
The following handling was proposed:
1) Before restarting neutron-server to apply new configuration, admin
undeploys all resources that were deployed with provider being removed.
That's needed to gracefully cleanup devices used by provider being removed.

2) Removal of a provider should not result in resource deletion.
E.g. user's logical resources are preserved, and they can be associated
with other service providers later on.

3) Having (1) and (2) it's obvious that after those steps are performed,
users are left with pure logical resources which don't have physical
representation.
I think such resources are no worse then deployed ones, e.g. could be
worked with just the same way as those which have a provider associated.

The conclusion from (3) is that users themselves may want to create such
resources.
The workflow would be to create resource with no provider, configure it,
and then deploy at once.

And I have an API question regarding such use case.
Currently user doesn't specify provider to create resource. For this to
continue to work we introduced the notion of 'default provider'. So, If
user doesn't specify provider - the default one is used.
Then if we want users to be able to create unassociated resource, what kind
of provider they need to pass to 'create' API call?

One important consideration that appeared while I was implementing multiple
providers for lbaas is that a resource always needs to be handled by some
provider, even if not associated with any. That is needed to preserve
consistency of DB operations, because in current model (for lbaas at least)
plugin sets object (pool, vip, etc) status to PENDING_DELETE, and then
driver deletes it.
If resource is unassociated with the driver, then 'Noop' driver must be
used for this logic to work properly.

One of the solution to this would be to have special name for the provider
to indicate 'Noop' provider. The reason for having special name is that
it's better to not specify Noop in configuration as it is essential basic
provider that should always be present.

Please share your thoughts.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130729/b11297ea/attachment.html>