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.hellm...@dreamhost.com<mailto:doug.hellm...@dreamhost.com>> wrote:




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

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




On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M 
<noo...@noorul.com<mailto:noo...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to