Open Stack

I have updated the blueprint for this feature, and approved the direction for the v0.1 milestone:

https://blueprints.launchpad.net/solum/+spec/command-line

The specification for the CLI is not intended to be complete at this stage. It only specified what I expect we will need for v0.1. Additional commands can be added as we add support for additional features in subsequent releases.

Adrian

On Nov 15, 2013, at 12:00 PM, Doug Hellmann <doug.hellmann at dreamhost.com<mailto:doug.hellmann at dreamhost.com>> wrote:




On Thu, Nov 14, 2013 at 2:28 AM, Adrian Otto <adrian.otto at rackspace.com<mailto:adrian.otto at rackspace.com>> wrote:
Doug,

On Nov 13, 2013, at 9:28 AM, Doug Hellmann <doug.hellmann at dreamhost.com<mailto:doug.hellmann at dreamhost.com>> wrote:




On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M <noorul at noorul.com<mailto:noorul at noorul.com>> wrote:

Hello all,

I registered a new blueprint [1] for command line client interface for
Solum. We need to decide whether we should have a separate repository
for this or go with new unified CLI framework [2]. Since Solum is not
part of OpenStack I think it is not the right time to go with the
unified CLI.

One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example:

  $ pip install python-solumclient
  $ pip install python-openstackclient
  $ openstack solum make me a paas

Dean has done a lot of work to design a consistent "noun-followed-by-verb" command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands).

Are you referring to "openstack solum …" in your suggestion of what not to do? If there is no project name in there, how would it work? Would we have a flat global namespace for all verbs?

I could imagine the following verb/noun combinations off the bat:

deploy app

list assemblies
list plans
list services

get assembly <assembly_name|uri>
get plan <plan_name|uri>
get service <service_name|uri>

scale assembly <assembly_name|uri> (+|-n)
resize du <assembly_name|uri>
start assembly
stop assembly

delete assembly
delete app

What about using combined noun+verb combinations, so you would end up with commands like:

deploy_app

…etc. That might be more specific and require less processing logic.

There is a namespace for the nouns, and each noun has a namespace with verbs. So you might say "openstack app deploy", "openstack assembly show", etc.
Placing the noun first lets us use tab completion to help the user figure out what options they have ("openstack assembly <tab>" would show scale, resize, start, and stop as completion options).


As far as processing logic, that's all handled by the framework already. The commands are registered as multi-word names pointing to a single class, and cliff figures out which one to run based on the input command line.

Doug



Thanks,

Adrian




Doug
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/c35b2099/attachment.html>