Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. OpenStack>
  3. Netstack
Re: About API v2.0 return value by list_xx
dan at nicira
Jun 5, 2012, 11:21 AM
Post #1 of 8 (2101 views)
Permalink
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 <gongysh@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 <rkukura@redhat.com> <rkukura@redhat.com> wrote: -----
> To: Yong Sheng Gong/China/IBM@IBMCN
> From: Robert Kukura <rkukura@redhat.com> <rkukura@redhat.com>
> Date: 06/06/2012 01:15AM
> Cc: dan wendlandt <dan@nicira.com> <dan@nicira.com>, gkotton@redhat.com,
> jason@koelker.net, Mark McLoughlin <markmc@redhat.com> <markmc@redhat.com>,
> Sumit Naiksatam <snaiksat@cisco.com> <snaiksat@cisco.com>, Somik Behera
> <somik@nicira.com> <somik@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 <rkukura@redhat.com> <rkukura@redhat.com> wrote:
> -----
> > To: Yong Sheng Gong/China/IBM@IBMCN
> > From: Robert Kukura <rkukura@redhat.com> <rkukura@redhat.com>
> > Date: 06/06/2012 12:07AM
> > Cc: dan wendlandt <dan@nicira.com> <dan@nicira.com>, gkotton@redhat.com,
> > jason@koelker.net, Mark McLoughlin <markmc@redhat.com><markmc@redhat.com>,
> Sumit Naiksatam
> > <snaiksat@cisco.com> <snaiksat@cisco.com>, Somik Behera
> <somik@nicira.com> <somik@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 <rkukura@redhat.com> <rkukura@redhat.com> wrote:
> -----
> >> To: Yong Sheng Gong/China/IBM@IBMCN
> >> From: Robert Kukura <rkukura@redhat.com> <rkukura@redhat.com>
> >> Date: 06/05/2012 11:26PM
> >> Cc: gkotton@redhat.com, jason@koelker.net, dan wendlandt
> >> <dan@nicira.com> <dan@nicira.com>, Mark McLoughlin <markmc@redhat.com><markmc@redhat.com>,
> Sumit Naiksatam
> >> <snaiksat@cisco.com> <snaiksat@cisco.com>, Somik Behera
> <somik@nicira.com> <somik@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: About API v2.0 return value by list_xx [ In reply to ]
jason at koelker
Jun 5, 2012, 12:09 PM
Post #2 of 8 (2060 views)
Permalink
On Tue, 2012-06-05 at 11:21 -0700, Dan Wendlandt wrote:
> 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 <gongysh@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.

I agree that the list of resources should not be wrapped in the resource
object. This slipped by in a refactoring. I updated the merge prop.

Happy Hacking!

7-11



--
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: About API v2.0 return value by list_xx [ In reply to ]
dan at nicira
Jun 5, 2012, 12:12 PM
Post #3 of 8 (2056 views)
Permalink
Ah, I messed up the order in my last email. You're right, v1.1 maps to
what nova does, and is what we should follow.

Jorge, I'd still be interested in whether there is a set of style
guidelines that we should use to guarantee consistency across openstack
APIs.

Thanks,

dan

On Tue, Jun 5, 2012 at 12:09 PM, Jason Kölker <jason@koelker.net> wrote:

> On Tue, 2012-06-05 at 11:21 -0700, Dan Wendlandt wrote:
> > 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 <gongysh@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.
>
> I agree that the list of resources should not be wrapped in the resource
> object. This slipped by in a refactoring. I updated the merge prop.
>
> Happy Hacking!
>
> 7-11
>
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: About API v2.0 return value by list_xx [ In reply to ]
jorge.williams at rackspace
Jun 5, 2012, 1:33 PM
Post #4 of 8 (2058 views)
Permalink
There are no formal style guidelines, but collection in compute follow the format that you labeled 1.1 below...this is also done by keystone, lbaas and others, so I think that's what you should follow.

I also think that you should make sure that you allow for pagination as described here:

http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html

-jOrGe W.


On Jun 5, 2012, at 2:12 PM, Dan Wendlandt wrote:

Ah, I messed up the order in my last email. You're right, v1.1 maps to what nova does, and is what we should follow.

Jorge, I'd still be interested in whether there is a set of style guidelines that we should use to guarantee consistency across openstack APIs.

Thanks,

dan

On Tue, Jun 5, 2012 at 12:09 PM, Jason Kölker <jason@koelker.net<mailto:jason@koelker.net>> wrote:
On Tue, 2012-06-05 at 11:21 -0700, Dan Wendlandt wrote:
> 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 <gongysh@cn.ibm.com<mailto:gongysh@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.

I agree that the list of resources should not be wrapped in the resource
object. This slipped by in a refactoring. I updated the merge prop.

Happy Hacking!

7-11





--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com/>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: About API v2.0 return value by list_xx [ In reply to ]
gongysh at cn
Jun 5, 2012, 3:48 PM
Post #5 of 8 (2067 views)
Permalink
thanks
I will consider the pagination.
Yong Sheng Gong


-----Jorge Williams <jorge.williams@rackspace.com> wrote: -----To: Dan Wendlandt <dan@nicira.com>
From: Jorge Williams <jorge.williams@rackspace.com>
Date: 06/06/2012 04:33AM
Cc: Jason Kölker <jason@koelker.net>, Yong Sheng Gong/China/IBM@IBMCN, "<gkotton@redhat.com>" <gkotton@redhat.com>, "Mark McLoughlin" <markmc@redhat.com>, Sumit Naiksatam <snaiksat@cisco.com>, "Somik Behera" <somik@nicira.com>, Robert Kukura <rkukura@redhat.com>, "<netstack@lists.launchpad.net>" <netstack@lists.launchpad.net>, Erik Carlin <erik.carlin@rackspace.com>
Subject: Re: About API v2.0 return value by list_xx

There are no formal style guidelines, but collection in compute follow the format that you labeled 1.1 below...this is also done by keystone, lbaas and others, so I think that's what you should follow.
I also think that you should make sure that you allow for pagination as described here:
http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html"]http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html
-jOrGe W.

On Jun 5, 2012, at 2:12 PM, Dan Wendlandt wrote:
Ah, I messed up the order in my last email. You're right, v1.1 maps to what nova does, and is what we should follow.
Jorge, I'd still be interested in whether there is a set of style guidelines that we should use to guarantee consistency across openstack APIs.
Thanks,
dan

On Tue, Jun 5, 2012 at 12:09 PM, Jason Kölker <jason@koelker.net> wrote:
On Tue, 2012-06-05 at 11:21 -0700, Dan Wendlandt wrote:
> 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"]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"]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 <gongysh@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.

I agree that the list of resources should not be wrapped in the resource
object. This slipped by in a refactoring. I updated the merge prop.

Happy Hacking!

7-11





--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: http://www.nicira.com/"]www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


Re: About API v2.0 return value by list_xx [ In reply to ]
heckj at me
Jun 10, 2012, 2:08 PM
Post #6 of 8 (2036 views)
Permalink
Yong -

The V3 keystone API is proposing taking a different tact from the "marker+limit" mechanism. Based on the suggestions from the Horizon devs, I'm proposing for the next API to enable a "page" and "pagesize" query parameter on all the GET requests, with a default pagesize set to 30 to specifically enable page forward and page backwards in the user interface.

-joe


On Jun 5, 2012, at 3:48 PM, Yong Sheng Gong wrote:
> thanks
> I will consider the pagination.
> Yong Sheng Gong
>
>
> -----Jorge Williams <jorge.williams@rackspace.com> wrote: -----
> To: Dan Wendlandt <dan@nicira.com>
> From: Jorge Williams <jorge.williams@rackspace.com>
> Date: 06/06/2012 04:33AM
> Cc: Jason Kölker <jason@koelker.net>, Yong Sheng Gong/China/IBM@IBMCN, "<gkotton@redhat.com>" <gkotton@redhat.com>, "Mark McLoughlin" <markmc@redhat.com>, Sumit Naiksatam <snaiksat@cisco.com>, "Somik Behera" <somik@nicira.com>, Robert Kukura <rkukura@redhat.com>, "<netstack@lists.launchpad.net>" <netstack@lists.launchpad.net>, Erik Carlin <erik.carlin@rackspace.com>
> Subject: Re: About API v2.0 return value by list_xx
>
> There are no formal style guidelines, but collection in compute follow the format that you labeled 1.1 below...this is also done by keystone, lbaas and others, so I think that's what you should follow.
>
> I also think that you should make sure that you allow for pagination as described here:
>
> http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html
>
> -jOrGe W.
>
>
> On Jun 5, 2012, at 2:12 PM, Dan Wendlandt wrote:
>
>> Ah, I messed up the order in my last email. You're right, v1.1 maps to what nova does, and is what we should follow.
>>
>> Jorge, I'd still be interested in whether there is a set of style guidelines that we should use to guarantee consistency across openstack APIs.
>>
>> Thanks,
>>
>> dan
>>
>> On Tue, Jun 5, 2012 at 12:09 PM, Jason Kölker <jason@koelker.net> wrote:
>> On Tue, 2012-06-05 at 11:21 -0700, Dan Wendlandt wrote:
>> > 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 <gongysh@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.
>>
>> I agree that the list of resources should not be wrapped in the resource
>> object. This slipped by in a refactoring. I updated the merge prop.
>>
>> Happy Hacking!
>>
>> 7-11
>>
>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 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
Re: About API v2.0 return value by list_xx [ In reply to ]
peter at nicira
Jun 11, 2012, 11:42 AM
Post #7 of 8 (2053 views)
Permalink
The problem with page/pagesize parameters for the API is that
retrieving all entities in a non-lossy way requires state storage on
the server (which is not allowed in REST). I understand the
cursor/limit approach is harder for the UI, but these clients already
need to handle problems of sorting, after which page-style pagination
is trivial.

- Peter

> From: Joseph Heck <heckj@me.com>
> Date: Sun, Jun 10, 2012 at 2:08 PM
> Subject: Re: [Netstack] About API v2.0 return value by list_xx
> To: Yong Sheng Gong <gongysh@cn.ibm.com>
> Cc: netstack@lists.launchpad.net, Jason Kölker <jason@koelker.net>, Jorge
> Williams <jorge.williams@rackspace.com>
>
>
> Yong -
>
> The V3 keystone API is proposing taking a different tact from the
> "marker+limit" mechanism. Based on the suggestions from the Horizon devs,
> I'm proposing for the next API to enable a "page" and "pagesize" query
> parameter on all the GET requests, with a default pagesize set to 30 to
> specifically enable page forward and page backwards in the user interface.
>
> -joe
>
>
> On Jun 5, 2012, at 3:48 PM, Yong Sheng Gong wrote:
>
> thanks
> I will consider the pagination.
> Yong Sheng Gong
>
>
> -----Jorge Williams <jorge.williams@rackspace.com> wrote: -----
> To: Dan Wendlandt <dan@nicira.com>
> From: Jorge Williams <jorge.williams@rackspace.com>
> Date: 06/06/2012 04:33AM
> Cc: Jason Kölker <jason@koelker.net>, Yong Sheng Gong/China/IBM@IBMCN,
> "<gkotton@redhat.com>" <gkotton@redhat.com>, "Mark McLoughlin"
> <markmc@redhat.com>, Sumit Naiksatam <snaiksat@cisco.com>, "Somik Behera"
> <somik@nicira.com>, Robert Kukura <rkukura@redhat.com>,
> "<netstack@lists.launchpad.net>" <netstack@lists.launchpad.net>, Erik Carlin
> <erik.carlin@rackspace.com>
> Subject: Re: About API v2.0 return value by list_xx
>
> There are no formal style guidelines, but collection in compute follow the
> format that you labeled 1.1 below...this is also done by keystone, lbaas and
> others, so I think that's what you should follow.
>
> I also think that you should make sure that you allow for pagination as
> described here:
>
> http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html
>
> -jOrGe W.
>
>
> On Jun 5, 2012, at 2:12 PM, Dan Wendlandt wrote:
>
> Ah, I messed up the order in my last email.  You're right, v1.1 maps to what
> nova does, and is what we should follow.
>
> Jorge, I'd still be interested in whether there is a set of style guidelines
> that we should use to guarantee consistency across openstack APIs.
>
> Thanks,
>
> dan
>
> On Tue, Jun 5, 2012 at 12:09 PM, Jason Kölker <jason@koelker.net> wrote:
>>
>> On Tue, 2012-06-05 at 11:21 -0700, Dan Wendlandt wrote:
>> > 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 <gongysh@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 'ACTYVE',
>> >                      u 'id': u '5d7c4e4e-366f-49a4-bec8-92f5610d01d9',
>> >                      u 'tags': []
>> >                  }
>> >              ,  {
>> >                      u 'subnets': [],
>> >                      u 'name': u 'private3',
>> >               A0      u 'admin_state_up': True,
>> >                      u 'op_status': u 'ACTIVE',
>> >                      u 'id': u '6bb9b6df-
>> >   A      4b81-41b5-8743-587d0b6147f9',
>> >                      u 'tags': []
>> >                  }
>> >             ]
>> >          }
>> >
>> > Y0       I think we should use 1.1 format.
>>
>> I agree that the list of resources should not be wrapped in the resource
>> object. This slipped by in a refactoring. I updated the merge prop.
>>
>> Happy Hacking!
>>
>> 7-11
>>
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
>
>
>
> --
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

--
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: About API v2.0 return value by list_xx [ In reply to ]
jorge.williams at rackspace
Jun 11, 2012, 4:07 PM
Post #8 of 8 (2059 views)
Permalink
Right. We had a huge discussion on pagination on the OpenStack mailing list back in the day. Most clients simply want to iterate through the collection and as Peter stated using a marker allows you to do this in a non-lossy way. Some of our customers (Rightscale, I think), complained a lot about this issue with our Cloud Servers 1.0 API which used limit offset approach -- which is why we changed it when we went OpenStack. Joe, I hope you reconsider.

Regardless of what approach you decide to take, you might also want to provide "next" links in collections. This allows the client to easily iterate through the list by simply following links. The approach is less error prone and it keeps the client from having to understand your query parameters etc.

-jOrGe W.


On Jun 11, 2012, at 1:42 PM, Peter Balland wrote:

> The problem with page/pagesize parameters for the API is that
> retrieving all entities in a non-lossy way requires state storage on
> the server (which is not allowed in REST). I understand the
> cursor/limit approach is harder for the UI, but these clients already
> need to handle problems of sorting, after which page-style pagination
> is trivial.
>
> - Peter
>
>> From: Joseph Heck <heckj@me.com>
>> Date: Sun, Jun 10, 2012 at 2:08 PM
>> Subject: Re: [Netstack] About API v2.0 return value by list_xx
>> To: Yong Sheng Gong <gongysh@cn.ibm.com>
>> Cc: netstack@lists.launchpad.net, Jason Kölker <jason@koelker.net>, Jorge
>> Williams <jorge.williams@rackspace.com>
>>
>>
>> Yong -
>>
>> The V3 keystone API is proposing taking a different tact from the
>> "marker+limit" mechanism. Based on the suggestions from the Horizon devs,
>> I'm proposing for the next API to enable a "page" and "pagesize" query
>> parameter on all the GET requests, with a default pagesize set to 30 to
>> specifically enable page forward and page backwards in the user interface.
>>
>> -joe
>>
>>
>> On Jun 5, 2012, at 3:48 PM, Yong Sheng Gong wrote:
>>
>> thanks
>> I will consider the pagination.
>> Yong Sheng Gong
>>
>>
>> -----Jorge Williams <jorge.williams@rackspace.com> wrote: -----
>> To: Dan Wendlandt <dan@nicira.com>
>> From: Jorge Williams <jorge.williams@rackspace.com>
>> Date: 06/06/2012 04:33AM
>> Cc: Jason Kölker <jason@koelker.net>, Yong Sheng Gong/China/IBM@IBMCN,
>> "<gkotton@redhat.com>" <gkotton@redhat.com>, "Mark McLoughlin"
>> <markmc@redhat.com>, Sumit Naiksatam <snaiksat@cisco.com>, "Somik Behera"
>> <somik@nicira.com>, Robert Kukura <rkukura@redhat.com>,
>> "<netstack@lists.launchpad.net>" <netstack@lists.launchpad.net>, Erik Carlin
>> <erik.carlin@rackspace.com>
>> Subject: Re: About API v2.0 return value by list_xx
>>
>> There are no formal style guidelines, but collection in compute follow the
>> format that you labeled 1.1 below...this is also done by keystone, lbaas and
>> others, so I think that's what you should follow.
>>
>> I also think that you should make sure that you allow for pagination as
>> described here:
>>
>> http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html
>>
>> -jOrGe W.
>>
>>
>> On Jun 5, 2012, at 2:12 PM, Dan Wendlandt wrote:
>>
>> Ah, I messed up the order in my last email. You're right, v1.1 maps to what
>> nova does, and is what we should follow.
>>
>> Jorge, I'd still be interested in whether there is a set of style guidelines
>> that we should use to guarantee consistency across openstack APIs.
>>
>> Thanks,
>>
>> dan
>>
>> On Tue, Jun 5, 2012 at 12:09 PM, Jason Kölker <jason@koelker.net> wrote:
>>>
>>> On Tue, 2012-06-05 at 11:21 -0700, Dan Wendlandt wrote:
>>>> 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 <gongysh@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 'ACTYVE',
>>>> u 'id': u '5d7c4e4e-366f-49a4-bec8-92f5610d01d9',
>>>> u 'tags': []
>>>> }
>>>> , {
>>>> u 'subnets': [],
>>>> u 'name': u 'private3',
>>>> A0 u 'admin_state_up': True,
>>>> u 'op_status': u 'ACTIVE',
>>>> u 'id': u '6bb9b6df-
>>>> A 4b81-41b5-8743-587d0b6147f9',
>>>> u 'tags': []
>>>> }
>>>> ]
>>>> }
>>>>
>>>> Y0 I think we should use 1.1 format.
>>>
>>> I agree that the list of resources should not be wrapped in the resource
>>> object. This slipped by in a refactoring. I updated the merge prop.
>>>
>>> Happy Hacking!
>>>
>>> 7-11
>>>
>>>
>>
>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 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
>>
>>
>>
>> --
>> 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
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>


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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal