[openstack-dev] Nova extension oddness?

Joshua Harlow harlowja at yahoo-inc.com
Thu Sep 6 19:48:34 UTC 2012


Awesomeness++

Looks like a step in the right direction, a slow one that will take a
while but will be a great overall goal imho.

I think getting at least basic orchestration in while also help, as the
natural transition from there is to make the states between those
transitions extendable (with the basics matching pretty much what is
already there). This is probably pretty far reaching, but would seem to
help in many different aspects (including being able to easily know when a
state craps out, and have rollback mechanisms between states - when
possible which makes for a more robust system). My only concern is that
can such a fundamental change actually get in, that¹s something I'm not so
sure about (but maybe its just best to slowly move it in...)

On 9/6/12 6:59 AM, "Andrew Bogott" <abogott at wikimedia.org> wrote:

>On 9/5/12 4:23 PM, Kevin L. Mitchell wrote:
>> On Wed, 2012-09-05 at 14:07 -0700, Joshua Harlow wrote:
>>> It seems like its almost like a extension here is a bundle of code that
>>> extends multiple parts no?
>> That would be a good way of doing it.  However, it's not the way that's
>> currently implemented in nova.  Right now, the only thing that can be
>> extended by loading a plugin‹in the context we're discussing‹is the
>> osapi itself.
>I have added a plugin framework to Folsom which addresses many of the
>concerns in this thread.
>
>http://wiki.openstack.org/novaplugin
>
>There's an attempt on that page to clarify terminology so that we can
>distinguish between plugins, extensions, and drivers.  So far I haven't
>gotten much traction with that, though, and the three terms seem to be
>used interchangeably within OpenStack.
>
>In my world, a plugin (as opposed to an Extension) is loaded via
>entrypoints (thus, does not need to be checked/merged into an OpenStack
>source tree), and provides several sets of hooks for injecting custom
>code into each service.  A plugin may or may not include extensions to
>an API.
>
>My hope is that the plugin framework will become an umbrella for project
>extensibility, but there will need to be a fair bit of planning and
>discussion on this topic.  In the meantime... http://xkcd.com/927/
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list