+1 for "1) Use `br` for client operations and `brooklyn` for server (original proposal)"
———————————————————— Gnu PGP key - http://is.gd/TTTTuI > On 23 Nov 2015, at 09:26, Alex Heneveld <[email protected]> > wrote: > > > There is a trend towards 2LAs (two-letter acronyms) for commands in devops -- > for instance `cf` and `tf` and of course `go`. We already have `brooklyn` as > a CLI for the *server*; however it does take a `launch` argument so we could > overload it: > > brooklyn launch # launch a server on localhost (new implementation as go > command calling to some java) > brooklyn login URL # connect to a server somewhere > brooklyn list # > > Though that is a bit confusing IMO. Or of course we could rename existing > bin/brooklyn as brooklyn-server, or go with broo. > > Seems to me we have several options: > > 1) Use `br` for client operations and `brooklyn` for server (original > proposal) > 2) Use `broo` for client operations and `brooklyn` for server (Svet's > proposal) > 3) Use `brooklyn` for both server and client operations (Andrea's proposal, > expanded above) > 4) Use `brooklyn` for client operations and `brooklyn-server` for server > operations (mod of Andrea's proposal) > > I'm for "1" -- in my usage the 2LAs become very natural, and we're lucky that > `br` is not a known *nix command. (And I don't think there is that much > potential for confusion with the HTML tag.) > > Best > Alex > > > On 20/11/2015 14:32, Andrea Turli wrote: >> 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]) >>>>>>> >>>> >
