Adding netstack again... please try to keep it CC'ed :) Yong, great that you're digging up these differences. Would be good to add an example of a "list" query to the wiki page: http://wiki.openstack.org/QuantumV2APIIntro
I don't have an opinion on one of the options below being fundamentally better than the other, but a general goal is to achieve consistency across different openstack APIs. The 2.0 approach does seem more inline with nova's list server method ( http://docs.openstack.org/api/openstack-compute/2/content/List_Servers-d1e2078.html#d6e1175), and such consistency seems like a good thing. Adding Jorge and Erik from Rackspace, as I really think we could benefit from openstack-wide consistency guidelines with respect to questions like this (as well as style items like camel-case vs. underscores vs. dashes). Dan On Tue, Jun 5, 2012 at 10:33 AM, Yong Sheng Gong <gong...@cn.ibm.com> wrote: > > Hi Jason, > I see some differences between returned values 1.1 and 2.0 api: > 2.0 list network: > { > u 'networks': [{ > u 'network': { > u 'subnets': [], > u 'name': u 'private3', > u 'admin_state_up': True, > u 'op_status': u 'ACTIVE', > u 'id': u '5d7c4e4e-366f-49a4-bec8-92f5610d01d9', > u 'tags': [] > } > }, { > u 'network': { > u 'subnets': [], > u 'name': u 'private3', > u 'admin_state_up': True, > u 'op_status': u 'ACTIVE', > u 'id': u '6bb9b6df- > 4b81-41b5-8743-587d0b6147f9', > u 'tags': [] > } > }] > } > 1.1 is: > { > u 'networks': [{ > u 'subnets': [], > u 'name': u 'private3', > u 'admin_state_up': True, > u 'op_status': u 'ACTIVE', > u 'id': u '5d7c4e4e-366f-49a4-bec8-92f5610d01d9', > u 'tags': [] > } > , { > u 'subnets': [], > u 'name': u 'private3', > u 'admin_state_up': True, > u 'op_status': u 'ACTIVE', > u 'id': u '6bb9b6df- > 4b81-41b5-8743-587d0b6147f9', > u 'tags': [] > } > ] > } > > I think we should use 1.1 format. > > Thanks > Yong sheng Gong > > -----Robert Kukura <rkuk...@redhat.com> <rkuk...@redhat.com> wrote: ----- > To: Yong Sheng Gong/China/IBM@IBMCN > From: Robert Kukura <rkuk...@redhat.com> <rkuk...@redhat.com> > Date: 06/06/2012 01:15AM > Cc: dan wendlandt <d...@nicira.com> <d...@nicira.com>, gkot...@redhat.com, > ja...@koelker.net, Mark McLoughlin <mar...@redhat.com> <mar...@redhat.com>, > Sumit Naiksatam <snaik...@cisco.com> <snaik...@cisco.com>, Somik Behera > <so...@nicira.com> <so...@nicira.com> > Subject: Re: API v2.0 network, port and subnet tag > > On 06/05/2012 01:00 PM, Yong Sheng Gong wrote: > > Do you need the command line like "create_net key1=value1 key2=value2 > ..."? > > or what is your format in your mind? > > Yes, but not really key-value pairs as might be provided by the tags in > the V2 API (I now have a better understanding of this, I think). I was > thinking something like: > > create_net [--device <device-name>] [--vlan_tag <vlan-tag>] <tenant-id> > <net-id> > > Plugins supporting the provider-network extension would honor these > optional parameters. > > I'm also considering a --type <network-type> parameter that would have > values such as flat, vlan, gre, etc., so that plugins could reject > requests to create network types they don't support. Simply ignoring > unrecognized optional parameters is probably not enough. > > -Bob > > > > > > > > > > > > -----Robert Kukura <rkuk...@redhat.com> <rkuk...@redhat.com> wrote: > ----- > > To: Yong Sheng Gong/China/IBM@IBMCN > > From: Robert Kukura <rkuk...@redhat.com> <rkuk...@redhat.com> > > Date: 06/06/2012 12:07AM > > Cc: dan wendlandt <d...@nicira.com> <d...@nicira.com>, gkot...@redhat.com, > > ja...@koelker.net, Mark McLoughlin <mar...@redhat.com><mar...@redhat.com>, > Sumit Naiksatam > > <snaik...@cisco.com> <snaik...@cisco.com>, Somik Behera > <so...@nicira.com> <so...@nicira.com> > > Subject: Re: API v2.0 network, port and subnet tag > > > > On 06/05/2012 11:46 AM, Yong Sheng Gong wrote: > >> Hi, > >> I am sorry for the wrong subject. > >> But I am talking about the v2.0 api tags table. > >> not the vlan tag. > > > > Sorry about that. Maybe the info I sent is useful and any feedback is > > very welcome. > > > > If you don't mind me asking, what is the role of tags and > > tag_associations in the V2 API and DB schema? Is this described > > somewhere? I need to know if this is something I should be leveraging in > > the provider-network BP. > > > > Also, my understanding is that you are rewriting python-quantumclient to > > some degree. Is that correct? If so, do you see any issue adding support > > for optional parameters to commands such as create_net? The current CLI > > really doesn't seem to be setup to parse optional command line > > parameters at all, and it seems this will be needed for the V2 API, so > > I've been holding off trying to hack something real in. I'm happy to add > > the provider-network optional params to python-quantumclient myself once > > the capability for optional parameters is there in the CLI, assuming it > > is coming. > > > > One other thought is that the 2nd phase of my provider-network work will > > need to extend the DB schema for at least the linuxbridge and > > openvswitch plugins to store the physical device/network identifier. > > This can probably be done in the vlan table that each of these currently > > has, but I'd need to know if any significant changes are coming via the > > V2 API work. > > > > Thanks, > > > > -Bob > > > >> > >> see https://review.openstack.org/#/c/8039/ > >> and attached figure > >> Yong Sheng Gong > >> > >> > >> > >> -----Robert Kukura <rkuk...@redhat.com> <rkuk...@redhat.com> wrote: > ----- > >> To: Yong Sheng Gong/China/IBM@IBMCN > >> From: Robert Kukura <rkuk...@redhat.com> <rkuk...@redhat.com> > >> Date: 06/05/2012 11:26PM > >> Cc: gkot...@redhat.com, ja...@koelker.net, dan wendlandt > >> <d...@nicira.com> <d...@nicira.com>, Mark McLoughlin > >> <mar...@redhat.com><mar...@redhat.com>, > Sumit Naiksatam > >> <snaik...@cisco.com> <snaik...@cisco.com>, Somik Behera > <so...@nicira.com> <so...@nicira.com> > >> Subject: Re: Change in openstack/quantum[master]: Implements the > >> blueprint use-common-cfg for the quantum serv... > >> > >> On 06/05/2012 10:59 AM, Gary Kotton wrote: > >>> On 06/05/2012 05:55 PM, Yong Sheng Gong wrote: > >>>> Hi Jason, > >>>> I am programming the client, I want to know how to create network with > >>>> tags. > >>> I have added Bob to the thread. This is something that he is working on > >>> i.e. connecting to existing networks. > >>> Thanks > >>> Gary > >>>> > >>>> Thanks > >>>> Yong Sheng Gong > >>> > >> > >> Hi Yong, > >> > >> Yes, I'm working on the provider-network blueprint that will extend the > >> create-network operation with additional optional parameters. I've been > >> hacking on the python-quantumclient to be able to test things, but > >> getting proper support for a set of optional parameters into the > >> create_net command line syntax that get added to the message body is > >> what's really needed. > >> > >> Initially, I'm adding an optional parameter to the existing > >> network-create message body that specifies the vlan tag to use. > >> Basically, if this parameter is present, the network is created using > >> that tag, and if it is not present, the plugin assigns the tag as it > >> does today. > >> > >> As a second step, I'll be adding a different optional parameter that > >> allows specification of the physical device to use. This will allow flat > >> networks and multiple vlan trunks to be supported. I'm not sure yet if > >> that param will name the a actual physical device (needing to be the > >> same on each host), will name a bridge (needing to be pre-configured on > >> each host), or will name an "abstract physical network" (needing to be > >> mapped to a device or bridge on each host), or maybe some combination of > >> these. > >> > >> Note that it will be possible to use the vlan-tag parameter without the > >> device parameter (when there is a single vlan trunk) or to use the > >> device parameter without a vlan-tag parameter to allow the tag to be > >> dynamically assigned within the specified trunk. > >> > >> Also, I will either use a special vlan tag value or a different optional > >> parameter to indicate that the network is "flat" (i.e. not a vlan tag). > >> > >> I'd also like to make sure the approach is extensible to allow > >> specification of existing GRE tunnels or other types of "provider > >> networks". This would probably be done by simply defining additional > >> optional parameters. > >> > >> As you can see, I haven't quite nailed down the exact set of optional > >> create-network parameters yet. I could propose a set in the next day or > >> so if you'd like, or maybe you could start with a "vlan_tag" optional > >> parameter, and we'll add/change things as they evolve. > >> > >> -Bob > >> > > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: 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
