Open Stack

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>