Support Unified Command Line Interface

Registered by Doug Hellmann

Move development of our command line client from the old per-project framework to the new unified command line tool framework.

http://wiki.openstack.org/UnifiedCLI

https://github.com/openstack/python-openstackclient

Blueprint information

Status:
Complete
Approver:
Julien Danjou
Priority:
Low
Drafter:
None
Direction:
Approved
Assignee:
ZhiQiang Fan
Definition:
Approved
Series goal:
Accepted for newton
Implementation:
Implemented
Milestone target:
milestone icon newton-3
Started by
gordon chung
Completed by
gordon chung

Related branches

Sprints

Whiteboard

should this go in as 'metering'? i vaguely recall reading we might want to deviate from calling the projects by their current purpose. -- gordc

I think so, if we need to use the purpose -- jd

I would expect to have commands like "meter list" and "meter summarize" (for the statistics, since "stats" isn't a verb). We will also need "meter sample list" for the raw sample data under a meter. I don't know what we'll do for working with resources, projects, and sources. Those are pretty generic terms. Maybe "metered resource list", "metered project list", and "meter source list"? Needs more thought. - dhellmann

how about 'meter aggregate' for statistics. for alarms, it would be meter alarm list? or is alarm list suffice.
also, do we need to 'ed' attached to meter for resource and project? i'm indifferent to the idea, but for discussion, since the format is <noun> <verb>, meter shouldn't be confused as a verb and it would make ceilometer commands start the same. -- gordc

aggregate seems like a good alternative to summarize. We don't have to prefix everything with meter, so I think just "alarm list", "alarm create", etc. for alarm commands -- the point is to create a flat namespace in the command line without requiring the user to know which service owns the things the commands operate on. I called the commands for the resources "metered resource" because "metered" is an adjective. To be consistent with other commands like "ip filtered list", that should probably be "resource metered list" and "project metered list" or something, although we'll have to see what the latter does to interfere with the keystone commands. - dhellmann

There will be issues around object name collisions. 'aggregate' is in compute, 'project' is in identity, etc. The wiki page has a master list of verbs and a description of what the user should expect each one to do, we probably need a similar list of nouns (I still prefer the word 'object' here but it is soooo overloaded) with description and the API they are associated with. Right now they are listed in the TOC by API so collision detection is a bit harder. --dtroyer

darn, i liked aggregate. what constitutes a collision? is it any word in an object name must be used in the same position and shouldn't reuse words across projects? we could get around project/user collision with identity if we don't support v1 client. although i'm sure we'll run into another collision eventually -- gordc

ceilometer-api is deprecated, aodh, panko, and gnocchi support this already. calling it a day -- gordc (2017.06)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.