Feature #4220
Add filterting options in kamaki
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
Add --property-like in image list
Refs: #4220
Add a filter_dicts_by_dict utils method
Refs: #4220
This is a multipurpose method to be used for CLI filtering
Try a unified filtering method in image ? list
Refs: #4220
Complete basic filters in image compute list
Refs: #4220
Impement basic/custom filters for server list
Refs: #4220
New filters: name[-like/-suffix/-prefix], flavor_id, image_id, metadata[-like]
Create _id/name_filter methods for all listings
Refs: #4220
Implement filters for flavor & exapdn 2 all lists
Refs: #4220
History
#1 Updated by Vangelis Koukis about 11 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 12 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 12 years ago
- % Done changed from 0 to 10
#4 Updated by Stavros Sachtouris almost 11 years ago
- % Done changed from 10 to 20
#5 Updated by Stavros Sachtouris almost 11 years ago
- % Done changed from 20 to 40
#6 Updated by Stavros Sachtouris almost 11 years ago
- % Done changed from 40 to 50
#7 Updated by Stavros Sachtouris almost 11 years ago
- % Done changed from 50 to 80
#8 Updated by Stavros Sachtouris almost 11 years ago
- Status changed from New to Resolved
- % Done changed from 80 to 100
#9 Updated by Stavros Sachtouris almost 11 years ago
- Status changed from Resolved to Closed