Open Stack

It seems like its almost like a extension here is a bundle of code that
extends multiple parts no? So when someone loads the extension you are
talking about they also have to load the extended compute manager... Is
that generally what you are talking about, maybe we need something like
that? I know plugins exist already for various components, but if the
extension model (where individual functions/classes could hook-in to the
various compute stages, for example) was more widespread, wouldn't that
solve your problem.

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?

On 9/5/12 1:40 PM, "Kevin L. Mitchell" <kevin.mitchell at rackspace.com>
wrote:

>On Wed, 2012-09-05 at 12:51 -0700, Joshua Harlow wrote:
>> In looking at how 'launch-index' works in the OS nova api (its used
>> when you spin up more than 1 instance in 1 api call) I was seeing that
>> extensions almost seem to be used as configuration 'flags', is that
>> the purpose? I always thought of an extension as something you could
>> hook-in that would override default behavior (which some of the
>> extensions seem to be doing), not something that was tied to the main
>> program  so tightly.
>
>The extensions shipped with nova are technically incubating features
>that are not part of the strict API spec.  The idea is that many of
>these would become first-class citizens in the next API spec.
>
>
>>         min_count = 1
>>         max_count = 1
>>         if self.ext_mgr.is_loaded('os-multiple-create'):
>>             ret_resv_id = server_dict.get('return_reservation_id',
>>False)
>>             min_count = server_dict.get('min_count', 1)
>>             max_count = server_dict.get('max_count', min_count)
>
>The problem here is that we currently only have a way of extending nova
>in terms of the manager classes and changes to the API; for the
>extension you're referencing here, it has to be coupled with changes to
>the underlying code.  The is_loaded() test you're seeing here is
>probably a change that Vish recently contributed to try to make these
>extensions actually optional.
>
>> This is in nova/api/openstack/computer/servers.py (~L700). Is that how
>> we want to proceed with extension, or does there need to be
>> refactoring to make the right 'hook-in' points be used; say have the
>> create server 'top' level code go through various 'states', where each
>> 'state' can be adjusted by an extension (more data added, different
>> configurationŠ), with no checking of extensions being loaded in the
>> top level code. There seems to be multiple cases of extensions being
>> used as boolean flags there and I wonder if that¹s the right approach?
>
>I think there's still a lot of work to do to make nova properly
>extensible.  Some of it will be solved by promoting at least some of the
>extensions to be first-class citizens (osapi v3?), but there's a lot
>more that's difficult or perhaps impossible to accommodate.  Take for
>instance the hypervisors extension's support for calling uptime on the
>hypervisor host; that required adding: a call to the RPC API so we could
>send a message to the appropriate compute node; the call in the compute
>node manager to make an appropriate call to the virt driver; and the
>implementation of the final call in the virt driver (for xenapi, this
>support involved adding behavior to one of the xenapi plugins).  The
>only piece of this that really could be made into a plugin of any form
>was the osapi extension itself.
>-- 
>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