Open Stack

On 07/16/2012 10:44 AM, Jason Kölker wrote:
> On Sun, 2012-07-15 at 23:52 -0400, Robert Kukura wrote:
>> [I've added Jason to the thread, since he implemented the V2 API mechanism.]
> 
> <snip>
> 
>>> 4. we will avoid to modify the core code as possible as we can. Maybe we
>>> can use some kind of pipeline pattern to deal with resource mapping
>>> dict, and view, and other make dict function for resources
>>
>> I've prototyped a very straightforward approach that minimizes
>> modification to the core. Its goal is to leverage the core's data-driven
>> V2 API mechanism, simply allowing the extension to add the data
>> describing the extended attributes.
>>
>> First, I've replaced the quantum/api/v2/views module with a data-driven
>> approach where each attribute in RESOURCE_ATTRIBUTE_MAP has an
>> is_visible boolean to control whether the attribute is visible in
>> response messages.
>>
>> Second, I've added a bit of code to quantum/api/v2/router.__init__ so
>> that it instantiates the
>> quantum.extensions.extensions.PluginAwareExtensionManager and calls an
>> extend_resources method on it, passing the version and the
>> RESOURCE_ATTRIBUTE_MAP. This method calls into an extend_resources
>> method on each extension, and merges data it returns into the
>> RESOURCE_ATTRIBUTE_MAP.
>>
>> This seems to do the job with very minimal core changes. It needs a bit
>> of cleanup before its ready to submit, and I need to think about unit
>> tests for it.
> 
> +1 for this approach. Its much closer to the tween model I'm a fan of,
> where the extensions live at the same layer of the wsgi stack, so we can
> share data easily.

Please take a close look at the WIP patch at
https://review.openstack.org/#/c/9849/. I'd like to get some consensus
on whether this approach is sufficient and on whether my minimalist
implementation of it is viable, then clean it up, add unit tests, etc.
Note that this extension mechanism is blocking progress (to some extent)
on the provider network BP that would make use of this.

> 
>>> 5. thinking about quantum client to work with extensions, such as to
>>> list current set of active extensions, what they do on core resources, 
>>> what command options are available etc.
>>
>> It would be nice if the client could be driven by data available from
>> the /extensions/<extension> resource in the server, but even having
>> knowledge built into the client or loaded by the client based on the
>> name of the extension supported by the server would be OK. But for now,
>> the "extra attributes" functionality of the client seems to do the job.
> 
> Although I love the idea of a client that automatically discovers what
> and how to do, I've yet to see one that doesn't spend more time
> "discovering" resources than performing an actual operation. I would
> advocate adding extensions to the client (though entry_points) so a
> given server side extension would require a client side extension as
> well if it needed to add commands or modify the arguments.

Sounds good to me. But this would be a separate bug or BP on the client
project, and does not seem to be absolutely required in order to move
forward on the server side.

> 
>>> 6. If we need to modify/augment core models in extension, how do we do this?
>>
>> Do you mean the core DB models? If so, I filed a separate bug report for
>> this: https://bugs.launchpad.net/quantum/+bug/1023156
> 
> Plugin notifiers just got added to openstack.common. Might be something
> to checkout. Otherwise extensions could then be able to take a query
> object modify (or change it) and return it to the db_api.

I'll take a look. Again, this aspect is not as urgent as the support for
extended attributes from the provider network BP perspective.

> 
> Happy Hacking!
> 
> 7-11
> 
> PS. Any reason not to be having this discussion on openstack-dev?

Definitely time to move it to the list, so I've done so.

Thanks,

-Bob

>