Feature #4220

Add filterting options in kamaki

Added by Dionysis Grigoropoulos almost 8 years ago. Updated almost 8 years ago.

Status:Closed Start date:08/08/2013
Priority:Medium Due date:08/28/2013
Assignee:Stavros Sachtouris % Done:

100%

Category:kamaki Spent time: 34.00 hours
Target version:v0.10 Estimated time:32.00 hours

Description

There should be filtering options for a lot of commands in kamaki. Eg.

-- "kamaki flavor list c 4 -r 1024" should print only flavors with 4 CPUs and 1024MB of RAM
-
"kamaki server list --os debian" should print VMs that are marked as debian in the os metadata

Associated revisions

Revision 2d1202ee
Added by Stavros Sachtouris almost 8 years ago

Add --property to image list

Refs: #4220

Also, fix various bugs introduced by utils re-writtings

Revision 5576a4eb
Added by Stavros Sachtouris almost 8 years ago

Add --property-like in image list

Refs: #4220

Revision 1716a15d
Added by Stavros Sachtouris almost 8 years ago

Add a filter_dicts_by_dict utils method

Refs: #4220

This is a multipurpose method to be used for CLI filtering

Revision 854222c7
Added by Stavros Sachtouris almost 8 years ago

Try a unified filtering method in image ? list

Refs: #4220

Revision fc48b144
Added by Stavros Sachtouris almost 8 years ago

Complete basic filters in image compute list

Refs: #4220

Revision 89ea97e1
Added by Stavros Sachtouris almost 8 years ago

Impement basic/custom filters for server list

Refs: #4220

New filters: name[-like/-suffix/-prefix], flavor_id, image_id, metadata[-like]

Revision 6d190dd1
Added by Stavros Sachtouris almost 8 years ago

Create _id/name_filter methods for all listings

Refs: #4220

Revision d8ff7b56
Added by Stavros Sachtouris almost 8 years ago

Implement filters for flavor & exapdn 2 all lists

Refs: #4220

Revision c79faeb5
Added by Stavros Sachtouris almost 8 years ago

Implement all filters for network list +user names

Refs: #4220, #4228

History

#1 Updated by Vangelis Koukis almost 8 years ago

It's OK to filter Flavors based on their defined attributes, e.g. RAM or number of CPUs, but it's not the same as filtering servers based on their OS.
There is no "OS" attribute for a server, it's just a user-defined metadata key, which our UI uses.

In the servers case, filtering for OS could be in the form of "get me all servers which have this metadata key defined", or
"get me all servers which have this metadata key set to that value".

Let's have a short discussion before implementing this feature.

#2 Updated by Stavros Sachtouris almost 8 years ago

  • Due date set to 08/28/2013
  • Estimated time set to 32.00

There are three types of filters in kamaki cli side:

A. supported by API Request
B. included in API Response
C. custom values set by users

if A is the case,
   the filter must be supported with an (optional) argument, e.g. image list --order=-
elif B is the case,
   kamaki will filter the response against the filter to print only the requested results e.g. image list --name-like='Debian'
elif C, which means that users can set custom metadata, then
   we should follow the naming conventions of each context and add the -key and -value suffices to filter custom metas by key and value
   e.g. in "image" context the custom metas are called "properties". So we have:
      [OK] image list --property=OS=Linux    //Keep only results with OS=Linux
      [OK] image list --property-key=OS      //Keep only results that have an OS=* property
      [NO] image list --property-value=Linux //Keep only results with at least one *=Linux property - WILL NOT BE IMPLEMENTED, seems meaningless for now
fi

If more than one filtering options are present, it results to a JOIN query.

About JOIN:
No elaborate join mechanisms for now. A more effective JOIN (with index) may be a good idea only if we need to filter really large responses. If that's the case, we should plan an optimization for a future version. For now, we should be content with a simple O(N) filtering mechanism.

#3 Updated by Stavros Sachtouris almost 8 years ago

  • % Done changed from 0 to 10

#4 Updated by Stavros Sachtouris almost 8 years ago

  • % Done changed from 10 to 20

#5 Updated by Stavros Sachtouris almost 8 years ago

  • % Done changed from 20 to 40

#6 Updated by Stavros Sachtouris almost 8 years ago

  • % Done changed from 40 to 50

#7 Updated by Stavros Sachtouris almost 8 years ago

  • % Done changed from 50 to 80

#8 Updated by Stavros Sachtouris almost 8 years ago

  • Status changed from New to Resolved
  • % Done changed from 80 to 100

#9 Updated by Stavros Sachtouris almost 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF