API: GET networks/{net_id}/detail is inefficient

Re-targeting for Essex-1

I am untargeting this bug from Essex-1.

The following bug is a prerequisite for solving this bug: https://bugs.launchpad.net/quantum/+bug/837535

Technically, the solution to this bug is straightforward (see attached branch). However we are relying on the fact that a single call to get_network_details return all the ports for the network as well in an attribute called net-ports.

Unfortunately, this behaviour breaks what is stated in Quantum_plugin_base.

From quantum_plugin_base.QuantumPluginBase.get_network_details:

        :returns: a sequence of mappings with the following signature:
                    {'net-id': uuid that uniquely identifies the
                                particular quantum network
                     'net-name': a human-readable name associated
                                 with network referenced by net-id
                     'net-ifaces': ['vif1_on_network_uuid',
                                    'vif2_on_network_uuid',...,'vifn_uuid']
                    }

So, in order to push this change to Gerrit I first need permission from the community to change the documentation of quantum_plugin_base to:

        :returns: a sequence of mappings with the following signature:
                    {'net-id': uuid that uniquely identifies the
                                particular quantum network
                     'net-name': a human-readable name associated
                                 with network referenced by net-id
                     'net-ports': a list of port resources describing the network's ports
                                           and attached interfaces
                    }

I don't see this as samething we need to decide ASAP, but it would be great if we can get the ball rolling.

I think this makes sense. I'm in favor of making such changes as early as possible in a release cycle, so perhaps we can do this early essex-2? We'll definitely need to send an email to the list for this one.

Targeting Essex-2 is not a problem.
After all, the technical issues here are really mininal; the real thing is to get the community to understand the discrepancy between the plugin interface and their implementation, and agree on a solution.

Getting the ball rolling on the mailing list sounds the right approach.

Hi Salv, doing some bug clean-up. Is this issue still relevant?

Dan,

let's bring this up in the next meeting. The issue in not extremely important, so I won't die if that is not fixed.
Actually, what bothers me a little is that the documentation for quantum_plugin_base differs from what the plugin actually do.
As I see it, it is quantum_plugin_base which should be updated.

k, added it to agenda

On Thu, Jan 12, 2012 at 4:25 AM, Salvatore Orlando <
<email address hidden>> wrote:

> Dan,
>
> let's bring this up in the next meeting. The issue in not extremely
> important, so I won't die if that is not fixed.
> Actually, what bothers me a little is that the documentation for
> quantum_plugin_base differs from what the plugin actually do.
> As I see it, it is quantum_plugin_base which should be updated.
>
> --
> You received this bug notification because you are a member of Netstack
> Core Developers, which is subscribed to quantum.
> https://bugs.launchpad.net/bugs/834012
>
> Title:
> API: GET networks/{net_id}/detail is inefficient
>
> Status in OpenStack Quantum (virtual network service):
> In Progress
>
> Bug description:
> This operation currently makes 3 calls to the plugin:
> 1 - retrieve network
> 2 - retrieve port list
> 3 - retrieve detail for port
>
> The first call only actuall should return all the information needed
> for creating the response.
>
> Fixing this bug implies also making sure that all the plugins are
> compliant with the interface specificed by quantum_plugin_base
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/quantum/+bug/834012/+subscriptions
>

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

The same applies to GET networks/{net_id}/ports/details

We need to get as much as possible for the plugin in order to do as less as possible in the API layer. For this reason the plugin, when invoking get_all_ports should accept an optional keyword parameter for loading port details as well.

Hi Salvatore, we got bit by an issue that I think is related here, in combination with another bug (https://bugs.launchpad.net/quantum/+bug/923510).

The latest version of _item in quantum/api/networks.py seems to make individual get_port_details() calls for each port, so I'm not sure the above discussion is still valid (either that, or I am misunderstanding the above discussion).

Let me know if you'll be able to fix this soon, otherwise I can try and have brad or dave take a look.

Untargeting and unassigning this bug.
There will not be enough time before E-4, and we haven't sorted out yet how to deal with the difference in specification between quantum_plugin_base and the actual implementation in the plugins.

This is no longer relevant for the v2.0 API, so I would vote for marking it wont-fix.

Hi,
I agree. A sufficient explanation should suffice.
Thanks
Gary

On 06/07/2012 05:50 PM, dan wendlandt wrote:
> This is no longer relevant for the v2.0 API, so I would vote for marking
> it wont-fix.
>