openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

Hi Irena,

Our pretty wimpy existing developer docs cover extensions:
http://wiki.openstack.org/QuantumDevelopment

Would be great if you and others could help expand these docs as you
identify gaps.  Thanks,

Dan


On Sat, Jun 2, 2012 at 12:16 PM, Irena Berezovsky <irenab@xxxxxxxxxxxx>wrote:

>  Dan, thank you very much for pointing to nova examples.****
>
> Following these examples and also
> http://wiki.openstack.org/WritingRequestExtensions guidelines I
> understand how to add extension to nova, but still has questions how to add
> it to Quantum.****
>
> Nova extensions make use of nova.api.openstack.extensions module and
> Quantum has its own implementation.****
>
> Can you please point to some documentation regarding writing Quantum
> extensions?  ****
>
> Thanks a lot,****
>
> Irena****
>
> ** **
>
> *From:* Dan Wendlandt [mailto:dan@xxxxxxxxxx]
> *Sent:* Saturday, June 02, 2012 8:57 PM
> *To:* Robert Kukura
> *Cc:* Irena Berezovsky; Salvatore Orlando; netstack@xxxxxxxxxxxxxxxxxxx;
> openstack@xxxxxxxxxxxxxxxxxxx
>
> *Subject:* Re: [Netstack] question on get_network_details api call****
>
> ** **
>
> Hi Irena, Bob, Salvatore, ****
>
> ** **
>
> Just catching up the thread, and looping the netstack and openstack lists
> in as well, as this info is general useful in my opinion.  ****
>
> ** **
>
> Our model with Quantum, like Nova, is that it is definitely ok to extend
> the content of a core object with additional attributes.  These attributes
> should be formatted properly as extended attribute, so that the "key" of
> the attribute is <extension-alias>:<attribute-name> ****
>
> ** **
>
> This is done pretty commonly within Nova.  Two simple examples are: ****
>
> - nova/api/openstack/compute/contrib/scheduler_hints.py****
>
> - nova/api/openstack/compute/contrib/extended_status.py****
>
> ** **
>
> I do not believe you need to (or should) modify the view-builder code for
> the core object when you want to add an extended attribute to it.  Instead,
> the extension framework has you write a wsgi controller specific to the
> extension that is inserted as its own stage into the wsgi request and
> response processing pipeline.  Thus, when the request is passed in, your
> code gets a chance to parse the data, and the the response is passed back,
> your code gets a chance to add data to it.  ****
>
> ** **
>
> Using the Nova code as example is probably the best bet if you can find a
> good example within quantum.  Quantum's extension framework (and several
> other openstack projects) all use essentially the same model. ****
>
> ** **
>
> Dan****
>
> ** **
>
> ** **
>
> On Sat, Jun 2, 2012 at 8:43 AM, Robert Kukura <rkukura@xxxxxxxxxx> wrote:*
> ***
>
> On 06/02/2012 05:02 AM, Irena Berezovsky wrote:
> > Hi,
> > Bob, Dan,
> > I ran into following wiki page:
> >
> http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf
> > 'port profile' is exactly what I was looking for to expose in the plugin.
> > I would like to add the port profile retrieval capability and contribute
> the implementation.
> >
> > Can you please advise if there is any disagreement on getting it into
> core API? Shall I do it via extension?
> > Bob, seems that you are dealing with similar issues.
> > What do you suggest?
> >
> > Thanks a lot,
> > Irena****
>
> Irena,
>
> I'm not sure there is any consensus around using a "network profile" for
> this. I did see that document as well as archived discussion about
> defining "port profile" and "network profile" as extensible collections
> of attributes. But the existing "port profile" extension looks to be
> Cisco-specific, and seems to serve a somewhat different purpose.
>
> My current thinking is that we'd be better off long term following the
> lead of Nova and other projects in supporting "extension data" within
> the existing resources instead of requiring introduction of a new
> resource just to hold plugin-specific attributes.
>
> But, in the short term, it might make the most sense for each extension
> just to provide its own resource extension with its attributes. That's
> what I'm tentatively planning to do for the provider-network blueprint,
> but would reconsider if there was consensus that either the "extension
> data" support or a more general "network profile" should be added now.
>
> -Bob****
>
>
>
> ****
>
> ** **
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt ****
>
> Nicira, Inc: www.nicira.com****
>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>
> ** **
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~