I agree with Svet, `br` sounds weird (too similar to <br> :) ) Why `brooklyn` is not good? I think autocompletion will help and `brooklyn` will be more mnemonic, maybe.
My minor comment, Andrea On Fri, 20 Nov 2015 at 14:28 David Lloyd <[email protected]> wrote: > The existing CLI caches the login details (URL, username, password) in file > ~/.brooklyn_cli, so I guess that we'll look initially at caching the other > IDs in this file. > > Dave. > > On 20 November 2015 at 13:18, Svetoslav Neykov < > [email protected]> wrote: > > > I see many of the commands using context (the cached entity). Where does > > the context go into? Can parallel shells calling into the cli have > > different contexts? > > Perhaps we should keep the CLI context free and present the user with a > > console for where context is needed (something similar to > > http://htty.github.io/htty/)? > > > > Personal preference to naming the executable broo. > > > > +1 to having aliases for where context is allowed, but should be careful > > with the lifetime of the aliases. > > > > Svet. > > > > > > > On 20.11.2015 г., at 15:06, Geoff Macartney < > > [email protected]> wrote: > > > > > > Perhaps we could have an “alias” command for applications etc, > something > > like > > > > > > br application list > > > ….// view the list of applications > > > br application alias myserver ID12ab > > > br application myserver add abc.yaml > > > br application myserver add def.yaml > > > br application myserver add xyz.yaml > > > > > > > > > ———————————————————— > > > Gnu PGP key - http://is.gd/TTTTuI > > > > > > > > >> On 20 Nov 2015, at 12:59, Aled Sage <[email protected]> wrote: > > >> > > >> Thanks, > > >> > > >> This looks really good. > > >> > > >> It will be great to have this, and to have a getting started guide > that > > is based on this new CLI. Many other tools in the devops space focus on > > this kind of client CLI (e.g. Docker, Cloud Foundry, etc). > > >> > > >> --- > > >> I'm not sure about the "br application cache <ID>", which sets the app > > id to be used for subsequent calls such as "br entity ...". If using IDs > > they are globally unique, so we could just miss out the app id (we'd need > > to add to the REST api to support that). > > >> > > >> Would we want to support logical names for apps/entities, rather than > > just IDs? The REST api supports looking up the app by its display name. > I'm > > not convinced we want to do that, but it certainly is simple/useful > > sometimes to use logical names. > > >> > > >> Aled > > >> > > >> > > >> On 20/11/2015 12:14, David Lloyd wrote: > > >>> Hi All, > > >>> > > >>> We’ve been thinking that it would be really useful for Brooklyn to > > have a > > >>> tool that provides a Command Line Interface (CLI) to augment the > > current > > >>> web based GUI and REST API. The proposal below outlines what we are > > >>> thinking of. We request comments from the community on the idea, and > > would > > >>> very much welcome suggestions for developing it. > > >>> > > >>> Comments can be made by replying to this email or by adding > > >>> comment/suggestions to this document: > > >>> > > > https://docs.google.com/document/d/1KNCHG--ExGevcGoJ3cRzcrjh3mWsZOzyCzRM_TpoGGo/edit?usp=sharing > > >>> > > >>> (and there are two comments on the document already) > > >>> > > >>> > > >>> Description of Proposal > > >>> > > >>> The current REST API provides a powerful way for controlling > Brooklyn, > > but > > >>> it is difficult to combine operations (using the output of a command > as > > >>> input to a second command) using the GUI or using the REST API on a > > command > > >>> line. We think that having a dedicated command line tool would make > it > > >>> easier for beginners and advanced users to control Brooklyn. > > >>> > > >>> Robert Moss has already done some excellent work on the ‘Go CLI > client > > for > > >>> Brooklyn REST API’ which can be found at > > brooklyncentral/brooklyn-cli. Our > > >>> intention with this proposal would be to build upon this work and > > implement > > >>> a set of commands that go beyond mirroring the REST API. We feel it > > would > > >>> be best to keep the CLI in its own repo (so it can follow the Go > > >>> conventions), for example with the name brooklyn-cli. > > >>> > > >>> We think that it is important for a CLI to be portable and to have as > > few > > >>> (if any) dependencies on other tools as possible. Go has the > > advantages of > > >>> compiling to native OS specific binaries that are statically linked, > so > > >>> avoids the need for installing dependencies (and getting the right > > >>> combination of versions!). It can also be compiled for multiple > > operating > > >>> systems, enabling a CLI to be built for servers and typical end user > > >>> systems. > > >>> > > >>> Some possible commands that the CLI may provide include: > > >>> > > >>> br login > > >>> > > >>> cache login credentials for the Brooklyn instance > > >>> > > >>> br application list > > >>> > > >>> show the list of applications > > >>> > > >>> br application show <ID> > > >>> > > >>> show details of application <ID> > > >>> > > >>> br application cache <ID> > > >>> > > >>> cache the application <ID> to be used with subsequent commands that > > require > > >>> an application ID. > > >>> > > >>> br application add <file|url> > > >>> > > >>> add (deploy) the specified application blueprint > > >>> > > >>> br entity list [-r] > > >>> > > >>> list the entities for an application, recursively if ‘-r’ specified > > >>> (having previously used ‘br application cache <ID>’) > > >>> > > >>> br entity show <ID> > > >>> > > >>> show the details for an entity > > >>> > > >>> br entity cache <ID> > > >>> > > >>> cache the entity <ID> to be used with subsequent commands that > require > > an > > >>> entity ID (to be discarded if a new application ID is set). > > >>> > > >>> br sensor list > > >>> > > >>> list the sensors for an application / entity > > >>> > > >>> (having previously used ‘br application cache <ID>’ and ‘br entity > > cache > > >>> <ID>’) > > >>> > > >>> br sensor show <Name> > > >>> > > >>> show the sensor value > > >>> > > >>> br sensor show service.isUp > > >>> > > >>> show the value of the service.isUp sensor on the previously specified > > >>> application / entity > > >>> > > >>> br effector list > > >>> > > >>> list the effectors for an application / entity > > >>> > > >>> br effector invoke <Name> "{<parameter map>}" > > >>> > > >>> run the effector <Name> for a previously cached application <ID> / > > entity > > >>> <ID> > > >>> > > >>> br catalog list > > >>> > > >>> show the list of available catalog items > > >>> > > >>> br catalog add <file|url> > > >>> > > >>> add the specified catalog entries > > >>> > > >>> br location list > > >>> > > >>> list the available locations > > >>> > > >>> br location show <ID> > > >>> > > >>> show details for location <ID> > > >>> > > >>> br location add "{locationSpec}" > > >>> > > >>> add the specified location > > >>> > > >>> It is intended that further commands would be added later such as: > > >>> > > >>> - > > >>> > > >>> br policy … > > >>> - > > >>> > > >>> br activity … > > >>> - > > >>> > > >>> etc. > > >>> > > >>> > > >>> Existing CLI > > >>> > > >>> For reference the implemented commands for the existing brooklyn-cli > > are: > > >>> > > >>> USAGE: > > >>> > > >>> br [global options] command [command options] [arguments...] > > >>> > > >>> VERSION: > > >>> > > >>> 0.0.0 > > >>> > > >>> COMMANDS: > > >>> > > >>> access Show access control > > >>> > > >>> activity Show the activity for an entity > > >>> > > >>> activity-children Show the child activities for an entity > > >>> > > >>> activity-stream Show the stream for a given activity > > >>> > > >>> add-catalog Add a new catalog item from the supplied YAML > > >>> > > >>> add-children Add a child or children to this entity from the > supplied > > YAML > > >>> > > >>> application Show the status and location of a running application > > >>> > > >>> applications Show the status and location of running applications > > >>> > > >>> catalog List the available catalog applications > > >>> > > >>> config Show the config for an application and entity > > >>> > > >>> create Create a new brooklyn application from the supplied YAML > > >>> > > >>> delete Delete a brooklyn application > > >>> > > >>> destroy-policy Destroy a policy > > >>> > > >>> effectors Show the list of effectors for an application and entity > > >>> > > >>> entities Show the entites for an application > > >>> > > >>> entity-children Show the children of an application's entity > > >>> > > >>> locations List the available locations > > >>> > > >>> login Login to brooklyn > > >>> > > >>> policies Show the list of policies for an application and entity > > >>> > > >>> policy Show the status of a policy for an application and entity > > >>> > > >>> rename-entity Rename an entity > > >>> > > >>> sensor Show the value of a sensor for an application and entity > > >>> > > >>> sensors Show the sensors for an application and entity > > >>> > > >>> set-config Set config for an entity > > >>> > > >>> spec Get the YAML spec used to create the entity, if available > > >>> > > >>> start-policy Start or resume a policy > > >>> > > >>> stop-policy Suspends a policy > > >>> > > >>> tree Show the tree of all applications > > >>> version Display the version of the connected Brooklyn > > >>> > > >>> > > >>> Geoff Macartney ([email protected]) > > >>> David Lloyd ([email protected]) > > >>> > > >> > > > > > > > >
