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]) > >>> > >> > > > >
