Mailing List Archive

On 05/31/2012 01:06 AM, Irena Berezovsky wrote:
> Hi,
>
> Adding some additional attributes to the 'get_network_details' in my
> plugin, I realized that Network View builder just puts network_id and
> network_name in the response and ignores anything else.
>
> Is there any special reason for this?
>
> Will it be correct to allow addition of other network attributes that
> plugin returns to the response message?
>
> Or better way is to add some extension to retrieve full network profile?
>
>
>
> Thanks a lot,
>
> */Irena /*
>
>
>
>
>

Irena,

I've run into the same issue trying to expose details such as VLAN and
interface ids for the provider-networks blueprint. I keep finding
references to "responses extensions" and "data extensions", but haven't
yet found if/how these can be implemented in quantum. It does seem
straightforward to get extension data into plugins, but getting it out
is turning out to be more complicated. Any ideas, anyone?

-Bob

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

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@redhat.com> 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, 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@nicira.com]
Sent: Saturday, June 02, 2012 8:57 PM
To: Robert Kukura
Cc: Irena Berezovsky; Salvatore Orlando; netstack@lists.launchpad.net; openstack@lists.launchpad.net
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@redhat.com<mailto:rkukura@redhat.com>> 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<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

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@mellanox.com>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@nicira.com]
> *Sent:* Saturday, June 02, 2012 8:57 PM
> *To:* Robert Kukura
> *Cc:* Irena Berezovsky; Salvatore Orlando; netstack@lists.launchpad.net;
> openstack@lists.launchpad.net
>
> *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@redhat.com> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

On 06/02/2012 01:56 PM, Dan Wendlandt wrote:
> 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.

Thanks Dan! I've now had some success implementing an extension that
creates a RequestExtension that adds extended attributes to the response
for a core resource. At least with JSON - I have not been able to figure
out how to do this for XML, if that is even possible in quantum.

> 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.

The above description sounds more like a ResourceExtension than a
RequestExtension. A ResourceExtension introduces a new Controller,
whereas a RequestExtension just adds a handler function called by the
core's RequestExtensionController. All examples and descriptions I've
seen use ResourceExtension to introduce a new type of resource. Are you
suggesting this mechanism can also be used to extend an existing core
resource? Would this have any advantage over using a RequestExtension? I
still don't see any way a ResourceExtension could add extended
attributes into an XML response.

>
> 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.

The nova and quantum code seem to have diverged significantly. The nova
examples use a nova.api.openstack.wsgi.extends decorator on methods of
an extension-implemented Controller to do "request extensions", but
quantum doesn't have this decorator. Also, nova uses XML templates that
are extensible, whereas the _serialization_metadata in quantum core
resources does not seem to be extensible.

At this point, quantum's RequestExtension mechanism seems able to do the
job for the provider-networks BP, assuming that a JSON-only solution is
acceptable. If both JSON and XML support are needed, then, unless I am
missing something, creating a new (sub-)resource using a
ResourceExtension (similar to the portstats extension) seems like the
only straightforward option.

-Bob

>
> Dan
>
>
> On Sat, Jun 2, 2012 at 8:43 AM, Robert Kukura <rkukura@redhat.com
> <mailto:rkukura@redhat.com>> 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
> <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 <http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>


--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp