<< working through quantum email backlog, in roughly chronological order >>
Hi Salvatore, As always, great write-up. Very clear. Everything in terms of the implementation section makes perfect sense and is very much in line with my thoughts. A few comments below. Dan - My main short-term driver for filtering is various queries made by the Quantum Manager. For example, in https://github.com/openstack/nova/blob/master/nova/network/quantum/quantum_connection.pythere is a get_port_by_attachment and a get_attached_ports call. The former in particular is very expensive. It seems like these calls would be handled by the with-interface and has-interface queries, which is great. - For string matching, as we assuming exact match only, or support for regex/glob? - Another interesting item to query on may be to find the net-id for a given port-id. This is a bit wonky, as a port-id is technically scoped by a net-id, but I think in many circumstances it could be convient to only have to store the port-id, with the ability to call up the network when needed. - Are there planned changes to the client lib (e.g., be able to take in a dict of key-value pairs, which is converted into params on the query string). Would this be a separate issue? If so, let's file. - Looks like we can just copy how the Nova API docs indicate the set of supported filters. One downside with that format though is that there no good typing (e.g., look at the server list command linked from the spec, which specifies a "dateTime" value but doesn't describe the format). - The issue of what to do with plugins that don't implement the filters is a tough question. I think that by updating our common sqlalchemy DB layer to handle filters, we will provide a good default datastore that any plugin can use. Plugins that choose to implement their own datastore would then figure out how to do their own filtering (filtering is likely to be very datastore specific, as it really comes down to what fields that datastore lets you index over), but that seems reasonable, since implementing a different datastore itself is a pretty big complexity leap. With that in mind, I am find with a fairly harsh failure if Quantum receives an API request with a filter, but the plugin does not support filters. Stated another way, I don't think its a good use of time to be building a datastore-agnostic filtering mechanism on top of the plugin layer, as any real plugin will want datastore-aware filtering. - On a related note, do you consider implementing filtering in the sqlalchemy layer part of this deliverable, or do we need a separate issue? - I believe Ying was going to look at implementing key-value tags in the API. Before we "freeze" the set of filters supported for 1.1, it would probably be a good idea to make sure we have a filter mechanism for searching on tags. On Tue, Dec 13, 2011 at 8:58 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote: > Hi, **** > > ** ** > > A full spec is now available for the API-filters blueprint.**** > > You can find it at http://wiki.openstack.org/quantum-api-filters or > checking the blueprint itself.**** > > ** ** > > Regards,**** > > Salvatore**** > > -- > 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 Networks: 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
