Howdy,

Currently base OpenStack driver class (OpenStack_1_1_NodeDriver) from which
other OpenStack based provider drivers such as Rackspace and HP Cloud
inherit from implements all the common functionality.

In addition to that, it also implements some functionality offered by
OpenStack extensions such as floating IPs and floating IP pools. Those
extensions might not be supported by all the OpenStack based providers.

This means that if you will try to use this method on a provider driver
which doesn't support it, you will get an ugly error message back.

Because of that, I have decided to refactor OpenStack classes a bit and
make the following changes:

1. New OpenStack_1_1_BaseNodeDriver base class which only implements common
OpenStack functionality exposed by the OpenStack API v1.1.

This class should never be instantiated directly. It should only be used as
a base class for other provider driver such as Rackspace and HP Cloud to
inherit from.

2. I've moved OpenStack extensions functionality to separate mixin classes.

This means that now all the OpenStack providers which implement floating IP
functionality should, in addition to the base class, also inherit
from OpenStackFloatingIPsExtensionMixin class.

3. I've updated affected OpenStack drivers (Rackspace and HP Cloud).

4. Modified OpenStack_1_1_NodeDriver to inherit from the base class and all
the extension mixin classes. This way this change is fully backward
compatible and this class will behave exactly the same as it did in the
past.

Proposed implementation is available at
https://github.com/Kami/libcloud/compare/trunk...openstack_driver_extensions_refactor

Benefits of this approach over the existing one:

1. It makes code nicer and easier to reuse.

2. It makes programmatic introspection easier (better automatic generated
documentation, etc.).

You can now know that some OpenStack based provider supports floating IP
functionality because those methods are present on the driver class.
Previously methods were always present so this was not always the case.

Open questions (not necessary blockers for getting those changes merged
into trunk):

1. We need to decide how to make this work better for people who use
OpenStack driver to connect to the OpenStack based cloud or OpenStack
installation.

Currently the OpenStack driver implements all the methods which is not
ideal.

Couple of options I can think of from top of my head:

1. Allow user to pass "extensions" argument to the OpenStack driver
constructor (e.g. extensions=['floating_ips']).

This argument specify which extension methods should be available to the
driver.

2. IIRC, OpenStack API exposes an endpoint which lists all the supported
extensions.

This means we could detect supported extensions during run-time and throw
NotImplemented exception or do something along those lines if some
extension method is not supported.

The disadvantage of this approach is that it's less explicit and makes
programmatic instrospection impossible since "capability detection" happens
during run time.

Questions? Comments? Feedback?

Thanks

Reply via email to