One other related point is that these filters are going to be in 1.1 only, which seems reasonable. However, if we want QuantumManager to be able to take advantage of the filters (which we definitely do), then we will need QuantumManager to be using 1.1 soon, which would mean we need to finalize 1.1 even sooner. Are there changes other than tags that are still outstanding for the 1.1 API?
Dan On Mon, Jan 2, 2012 at 5:42 PM, Dan Wendlandt <d...@nicira.com> wrote: > << 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
