Mailing List Archive

api extensions question
On Mon, Jun 11, 2012 at 6:15 AM, Robert Kukura <rkukura@redhat.com> wrote:

> On 06/10/2012 03:19 PM, Irena Berezovsky wrote:
> > Hi Robert,
> > May I add to your question also considerations regarding network
> creation - POST operation?
> > I may be wrong in my understanding, but it seems to me that in case of
> RequestExtension it will be possible to create Provider Network via a
> single call.
> > In case of ResourceExtension it will require 2 calls; one for network
> creation and second for "provider" attributes setting for previously
> created network. Am I right?
> > In case of ResourceExtension Plugin on network creation should behave
> differently for "provider" and other(virtual) network, i.e. skip VLAN
> allocation. Seems that Plugin should be aware about Network type already
> during network creation.
> > What do you think?
>
> Hi Irena,
>
> I'd like to avoid this sort of two-step resource creation process.
> Adding new optional arguments to the existing POST operation that
> creates a new resource such as network seems to work, at least with
> JSON. I haven't looked into XML support for this yet. These arguments
> get passed through to the plugin as kwargs. Their names should use the
> extension's namespace prefix, but otherwise I don't think any explicit
> support in the extension framework is involved.
>

Just shoving values into a post and having them passed in as kwargs works
(we've done this in the past), but what I don't like about that approach is
that if we don't actually use an extension, there's no good way for an API
user to query the set of supported extensions and see if that extension is
running. Likewise, if extra arguments are passed into the plugin as
kwargs, an API might pass them in and believe they were accepted, when in
fact they were just ignored by the plugin.

Dan


>
> -Bob
>
> >
> > Thanks,
> > Irena
> >
> > -----Original Message-----
> > From: netstack-bounces+irenab=mellanox.com@lists.launchpad.net [mailto:
> netstack-bounces+irenab=mellanox.com@lists.launchpad.net] On Behalf Of
> Robert Kukura
> > Sent: Friday, June 08, 2012 6:21 PM
> > To: Dan Wendlandt; netstack@lists.launchpad.net
> > Subject: [Netstack] Provider Networks extension advice (was Re:
> [Openstack] question on get_network_details api call)
> >
> > Dan, Netstackers,
> >
> > I need some advice ASAP so I can proceed with the provider-networks BP
> > (https://blueprints.launchpad.net/quantum/+spec/provider-networks)
> > implementation. This BP will be implemented using a "provider" extension
> that adds a number of optional attributes (eg. vlan tags) to the core
> network resource. These attributes will be settable by and visible to those
> with admin rights.
> >
> > The main decision I'm looking for advice on is whether to implement this
> extension as a RequestExtension or as a ResourceExtension. See the email
> quoted below for details.
> >
> > If implemented as a RequestExtension, these provider attributes would be
> returned along with the core attributes from "GET
> /tenants/{tenant_id}/networks/{network_id}.json", and potentially from all
> API actions that return the core attributes.
> >
> > If implemented as a ResourceExtension, the provider attributes would be
> accessed from a separate sub-resource, such as "GET
> /tenants/{tenant_id}/networks/{network_id}/provider.json".
> >
> > As Dan suggested below, I think it would be preferable to extend the
> core resource itself rather than define a new sub-resource. This would mean
> using the RequestExtension approach. The issue with this is that I see no
> way to support XML with this approach, but the ResourceExtension approach
> can support both JSON and XML.
> >
> > Is the RequestExtension approach preferable? Is it acceptable even if it
> cannot (currently) support XML? Or is there a way to extend the XML using a
> RequestExtension that I'm missing?
> >
> > Thanks,
> >
> > -Bob
> >
> >
> > On 06/07/2012 05:19 PM, Robert Kukura wrote:
> >> 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/~openstack
> >> Post to : openstack@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help : https://help.launchpad.net/ListHelp
> >
> >
> > --
> > Mailing list: https://launchpad.net/~netstack
> > Post to : netstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~netstack
> > More help : https://help.launchpad.net/ListHelp
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: api extensions question [ In reply to ]
On 06/11/2012 11:28 AM, Dan Wendlandt wrote:
>
>
> On Mon, Jun 11, 2012 at 6:15 AM, Robert Kukura <rkukura@redhat.com
> <mailto:rkukura@redhat.com>> wrote:
>
> On 06/10/2012 03:19 PM, Irena Berezovsky wrote:
> > Hi Robert,
> > May I add to your question also considerations regarding network
> creation - POST operation?
> > I may be wrong in my understanding, but it seems to me that in
> case of RequestExtension it will be possible to create Provider
> Network via a single call.
> > In case of ResourceExtension it will require 2 calls; one for
> network creation and second for "provider" attributes setting for
> previously created network. Am I right?
> > In case of ResourceExtension Plugin on network creation should
> behave differently for "provider" and other(virtual) network, i.e.
> skip VLAN allocation. Seems that Plugin should be aware about
> Network type already during network creation.
> > What do you think?
>
> Hi Irena,
>
> I'd like to avoid this sort of two-step resource creation process.
> Adding new optional arguments to the existing POST operation that
> creates a new resource such as network seems to work, at least with
> JSON. I haven't looked into XML support for this yet. These arguments
> get passed through to the plugin as kwargs. Their names should use the
> extension's namespace prefix, but otherwise I don't think any explicit
> support in the extension framework is involved.
>
>
> Just shoving values into a post and having them passed in as kwargs
> works (we've done this in the past), but what I don't like about that
> approach is that if we don't actually use an extension, there's no good
> way for an API user to query the set of supported extensions and see if
> that extension is running. Likewise, if extra arguments are passed into
> the plugin as kwargs, an API might pass them in and believe they were
> accepted, when in fact they were just ignored by the plugin.

Good points Dan. I'm definitely exposing the provider-networks
functionality as a proper extension so it can be queried, etc. As I
mentioned, the extended request and response body attributes will belong
to the provider extension namespace.

Regarding the "ignored by the plugin" point, I've been thinking the
extension should define a provider:network_type argument. Any plugin
supporting the provider extension would be required to raise an
exception if the network_type argument indicated a type that it didn't
support. Each value of network_type would correspond to a set of
additional arguments (i.e. provider:vlan_id) that a plugin supporting
that network_type would need to honor. The default value for
network_type would be 'virtual', indicating the standard quantum
functionality is desired. Initial network_type values would be
'virtual', 'vlan', and 'flat', and maybe 'gre' for openvswitch. Does
something like this make sense?

-Bob

>
> Dan
>
>
>
> -Bob
>
> >
> > Thanks,
> > Irena
> >
> > -----Original Message-----
> > From: netstack-bounces+irenab=mellanox.com@lists.launchpad.net
> <mailto:mellanox.com@lists.launchpad.net>
> [mailto:netstack-bounces+irenab
> <mailto:netstack-bounces%2Birenab>=mellanox.com@lists.launchpad.net
> <mailto:mellanox.com@lists.launchpad.net>] On Behalf Of Robert Kukura
> > Sent: Friday, June 08, 2012 6:21 PM
> > To: Dan Wendlandt; netstack@lists.launchpad.net
> <mailto:netstack@lists.launchpad.net>
> > Subject: [Netstack] Provider Networks extension advice (was Re:
> [Openstack] question on get_network_details api call)
> >
> > Dan, Netstackers,
> >
> > I need some advice ASAP so I can proceed with the provider-networks BP
> > (https://blueprints.launchpad.net/quantum/+spec/provider-networks)
> > implementation. This BP will be implemented using a "provider"
> extension that adds a number of optional attributes (eg. vlan tags)
> to the core network resource. These attributes will be settable by
> and visible to those with admin rights.
> >
> > The main decision I'm looking for advice on is whether to
> implement this extension as a RequestExtension or as a
> ResourceExtension. See the email quoted below for details.
> >
> > If implemented as a RequestExtension, these provider attributes
> would be returned along with the core attributes from "GET
> /tenants/{tenant_id}/networks/{network_id}.json", and potentially
> from all API actions that return the core attributes.
> >
> > If implemented as a ResourceExtension, the provider attributes
> would be accessed from a separate sub-resource, such as "GET
> /tenants/{tenant_id}/networks/{network_id}/provider.json".
> >
> > As Dan suggested below, I think it would be preferable to extend
> the core resource itself rather than define a new sub-resource. This
> would mean using the RequestExtension approach. The issue with this
> is that I see no way to support XML with this approach, but the
> ResourceExtension approach can support both JSON and XML.
> >
> > Is the RequestExtension approach preferable? Is it acceptable even
> if it cannot (currently) support XML? Or is there a way to extend
> the XML using a RequestExtension that I'm missing?
> >
> > Thanks,
> >
> > -Bob
> >
> >
> > On 06/07/2012 05:19 PM, Robert Kukura wrote:
> >> 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>
> >>> <mailto: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>
> <http://www.nicira.com>
> >>> twitter: danwendlandt
> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@lists.launchpad.net
> <mailto:openstack@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help : https://help.launchpad.net/ListHelp
> >
> >
> > --
> > Mailing list: https://launchpad.net/~netstack
> > Post to : netstack@lists.launchpad.net
> <mailto:netstack@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~netstack
> > More help : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
Re: api extensions question [ In reply to ]
On Mon, Jun 11, 2012 at 12:31 PM, Robert Kukura <rkukura@redhat.com> wrote:
>
> >
> >
> > Just shoving values into a post and having them passed in as kwargs
> > works (we've done this in the past), but what I don't like about that
> > approach is that if we don't actually use an extension, there's no good
> > way for an API user to query the set of supported extensions and see if
> > that extension is running. Likewise, if extra arguments are passed into
> > the plugin as kwargs, an API might pass them in and believe they were
> > accepted, when in fact they were just ignored by the plugin.
>
> Good points Dan. I'm definitely exposing the provider-networks
> functionality as a proper extension so it can be queried, etc. As I
> mentioned, the extended request and response body attributes will belong
> to the provider extension namespace.
>
> Regarding the "ignored by the plugin" point, I've been thinking the
> extension should define a provider:network_type argument. Any plugin
> supporting the provider extension would be required to raise an
> exception if the network_type argument indicated a type that it didn't
> support.


My concern was actually about if someone was running a plugin that didn't
know about the "provider extension" at all. That value would be passed to
the plugin as a kwarg and just ignored, not raising an error. So the API
caller would think their request for a particular network type succeeded,
when in fact it failed. Now technically every client should check to make
sure the API lists the extension as supported before using it, but I'd
prefer a model where any non-core request attribute must either be
supported by a running extension, or the request generates an error. This
also helps with the fact that people might typo a field in an API request.


> Each value of network_type would correspond to a set of
> additional arguments (i.e. provider:vlan_id) that a plugin supporting
> that network_type would need to honor. The default value for
> network_type would be 'virtual', indicating the standard quantum
> functionality is desired. Initial network_type values would be
> 'virtual', 'vlan', and 'flat', and maybe 'gre' for openvswitch. Does
> something like this make sense?
>

For tackling the basic use case of mapping a Quantum network directly to a
VLAN, I think this type of an approach works. As I mentioned on the
blueprint whiteboard (
https://blueprints.launchpad.net/quantum/+spec/provider-networks), for more
advanced use cases such as linking Quantum networks to multiple "external
networks" outside of Quantum's control, I think Ian's suggestion about
modeling these external networks as entities that can "plug" into a Quantum
port is more flexible. In this model, you view Quantum networks as
entirely virtual, with an "uplink" to one or more external networks via
certain ports (of course, the implementation could just be that the plugin
uses a one-to-one mapping between an internal and external VLAN).

I think this port approach is more expressive (multiple external networks
can be described, external networks can be added/removed dynamically),
though I think one could argue that it makes the basic VLAN use case more
complex (one must create a network, and an uplink port, rather than just
creating a network with a bit of extra vlan info).

I'm also not a big fan of the fact that if you had a more complex network
type that had multiple attributes, those would all just be added in with
the create network request. I'd rather have each new "network_type" define
a URL in the API that allows you to connect that type of an external
network to a Quantum network. For example, the basic vlan case might work
like this:

POST /v2.0/networks

{ name: "public-net", cidr: "20.0.0.0/18"}

response ==> { uuid: "XYZ" }

This network might be uplinked to a local VLAN within the datacenter using:

POST /v2.0/extensions/hypervisor_vlan_uplinks

{ "network_id": "XYZ", <--- UUID of the quantum network to create uplink
on
"vlan_id": 44,
"phys_net_id": "eth0" <----- need some kind of an indicator if the
hypervisor has access to multiple NICs connected to different networks
}

response ===> { port_id: "ABC"} <---- hypervisor server creates a port
on network XYZ that "uplinks" to vlan 44 via eth0 of each hypervisor.

But network XZY could also be uplinked to a remote customer premises using
a similar model:

POST /v2.0/extensions/customer_vpn_uplinks

{ "network_id": "XYZ",
"vpn_credentials": "xxxxxxx"
}

response ====> { port_id: "DEF" }


I think there are a lot of wrinkles to solving this more general problem
and I know you're looking to keep things simple for this blueprint during
F-2, so perhaps the best think is to just focus on an extension for the
basic VLAN use case. I suspect my response was more than you were
bargaining for :)

Dan




>
> -Bob
>
> >
> > Dan
> >
> >
> >
> > -Bob
> >
> > >
> > > Thanks,
> > > Irena
> > >
> > > -----Original Message-----
> > > From: netstack-bounces+irenab=mellanox.com@lists.launchpad.net
> > <mailto:mellanox.com@lists.launchpad.net>
> > [mailto:netstack-bounces+irenab
> > <mailto:netstack-bounces%2Birenab>=mellanox.com@lists.launchpad.net
> > <mailto:mellanox.com@lists.launchpad.net>] On Behalf Of Robert
> Kukura
> > > Sent: Friday, June 08, 2012 6:21 PM
> > > To: Dan Wendlandt; netstack@lists.launchpad.net
> > <mailto:netstack@lists.launchpad.net>
> > > Subject: [Netstack] Provider Networks extension advice (was Re:
> > [Openstack] question on get_network_details api call)
> > >
> > > Dan, Netstackers,
> > >
> > > I need some advice ASAP so I can proceed with the
> provider-networks BP
> > > (https://blueprints.launchpad.net/quantum/+spec/provider-networks)
> > > implementation. This BP will be implemented using a "provider"
> > extension that adds a number of optional attributes (eg. vlan tags)
> > to the core network resource. These attributes will be settable by
> > and visible to those with admin rights.
> > >
> > > The main decision I'm looking for advice on is whether to
> > implement this extension as a RequestExtension or as a
> > ResourceExtension. See the email quoted below for details.
> > >
> > > If implemented as a RequestExtension, these provider attributes
> > would be returned along with the core attributes from "GET
> > /tenants/{tenant_id}/networks/{network_id}.json", and potentially
> > from all API actions that return the core attributes.
> > >
> > > If implemented as a ResourceExtension, the provider attributes
> > would be accessed from a separate sub-resource, such as "GET
> > /tenants/{tenant_id}/networks/{network_id}/provider.json".
> > >
> > > As Dan suggested below, I think it would be preferable to extend
> > the core resource itself rather than define a new sub-resource. This
> > would mean using the RequestExtension approach. The issue with this
> > is that I see no way to support XML with this approach, but the
> > ResourceExtension approach can support both JSON and XML.
> > >
> > > Is the RequestExtension approach preferable? Is it acceptable even
> > if it cannot (currently) support XML? Or is there a way to extend
> > the XML using a RequestExtension that I'm missing?
> > >
> > > Thanks,
> > >
> > > -Bob
> > >
> > >
> > > On 06/07/2012 05:19 PM, Robert Kukura wrote:
> > >> 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>
> > >>> <mailto: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>
> > <http://www.nicira.com>
> > >>> twitter: danwendlandt
> > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >>>
> > >>
> > >>
> > >> _______________________________________________
> > >> Mailing list: https://launchpad.net/~openstack
> > >> Post to : openstack@lists.launchpad.net
> > <mailto:openstack@lists.launchpad.net>
> > >> Unsubscribe : https://launchpad.net/~openstack
> > >> More help : https://help.launchpad.net/ListHelp
> > >
> > >
> > > --
> > > Mailing list: https://launchpad.net/~netstack
> > > Post to : netstack@lists.launchpad.net
> > <mailto:netstack@lists.launchpad.net>
> > > Unsubscribe : https://launchpad.net/~netstack
> > > More help : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com <http://www.nicira.com>
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>
>
>


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