Open Stack

Agreed 100% sometimes subclassing is the way to go but its not the best
for all cases.

Probably having hook-in points would I think be the most flexible, letting
the top level nova orchestration arbitrate to the basic hook-ins (whatever
defaults those are) and let others add there own hook-ins as they wish (or
if they want subclass it and do there thing that way). It does seem like a
lot of change though, but it does seem like the right way to go in the
end, just a question of how to get there :-P I'm not even sure the path
for that without a distributive change, lol.

Apaches model is similar, where u hook-in to various module functions and
modify an object that is passed around (the request object), it seems like
a pattern that could be useful to follow, with the main 'nova' engine
acting as the orchestrator for all things nova.

On 9/5/12 2:23 PM, "Kevin L. Mitchell" <kevin.mitchell at rackspace.com>
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.
>
>> So when someone loads the extension you are
>> talking about they also have to load the extended compute manager...
>
>The problem with that approach is that it is not properly extensible.
>Consider someone who wants to use two independent extensions which do
>two different things, but both require changes to the compute manager;
>if we simply extend the compute manager class, only one of the
>extensions can be used at a time.
>
>> Then when this extension that needs these extra calls is used, it has to
>> basically be a bundle of code that hooks in to the X various points
>> (instead of just 1 point at the extension webservice). Perhaps improving
>> upon the extension mechanism is in order (or making it more widely
>> distributed?), it seems like plugins are themselves extensions, so
>>maybe a
>> unified way of doing this would be applicable?
>
>At present, there is no way of extending the various managers except by
>subclassing, which is not scalable.  Hooks would probably be a very good
>first pass at improving extensibility.
>-- 
>Kevin L. Mitchell <kevin.mitchell at rackspace.com>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev