On 21 July 2016 at 04:56, Bence Romsics <bence.roms...@gmail.com> wrote:
> Hi, > > Looking at all the trunk port patches nicely coming along I was > wondering where do we want to see all the subport details in the API? > > In the spec a trunk object does not have a 'sub_ports' attribute: > > > http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html#rest-api-impact This was added so that you can create trunk with sub_ports at once and avoid two API calls. > > > Instead subports can be added/removed/queried via extra resource actions > like: > This is not either/or, you can do both: create a trunk just with a parent port and add sub_ports at a later date, or do both at once. > > PUT /v2.0/trunks/$trunk_id/add_subports > PUT /v2.0/trunks/$trunk_id/remove_subports > GET /v2.0/trunks/$trunk_id/get_subports > > IIRC the reasoning was to give control to the API user if/when he > wants to see the subport details, because that may be huge (for up to > 4k subports). > Payloads at scale can be big, have you ever tried to list a network with a gazillion subnets? > > The current patches mostly go the other way, having a sub_ports > attribute on the trunk. Consistent with that > /v2.0/trunks/$trunk_id/get_subports is not implemented. > > I don't think so, I think the rationale is to make the API less chatty than it needs to be. The spec was particularly lax about this, and it did not prescribe any behavior so I would not state that we went the other way. > So which way do we want this? I think the way it is now is what we want. > If we stick to the currently implemented approach I guess we can drop > the get_subports action, right? > The get_subports may seem redundant, but I'd avoid an overly aggressive optimization at this point. The CLI can nicely show the ports in tabular form when invoked. > > Cheers, > Bence Romsics > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
