+1 `brooklyn` for server +1 2-letter command for client ops, but propose `bk` as the abbreviation[1]
[1] That's how we New Yorkers do it On Mon, Nov 23, 2015 at 6:59 AM Aled Sage <[email protected]> wrote: > +1 for option (1): "br". > > If we're doing single transferable vote [1], then my second preference > would be (3) with the understanding that the brooklyn server-side > command may change substantially when we switch to Karaf. We should also > be moving to using something like `service brooklyn start` for the > server-side, so we could live with the name clash in the mean time. > > Aled > > [1] http://www.electoral-reform.org.uk/single-transferable-vote > > > On 23/11/2015 11:45, Hadrian Zbarcea wrote: > > I also like 'brooky' for some weird reason, but +1 for 'br'. > > > > Hadrian > > > > On 11/23/2015 04:26 AM, Alex Heneveld 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]) > >>>>>>>> > >>>>> > >> > >
