+1 for option 1 style - but using Mike's suggestion of bk On 24 November 2015 at 08:25, Mark McKenna <[email protected]> wrote:
> +1 for option 1 > +1 For Mikes suggestion of "bk" over "br" > > On Tue, 24 Nov 2015, 00:12 Mike Zaccardo <[email protected]> > wrote: > > > +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]) > > > >>>>>>>> > > > >>>>> > > > >> > > > > > > > > > -- > > *Mark McKenna* > > *Twitter :: @m4rkmckenna <https://twitter.com/m4rkmckenna>* > > *PGP :: public-key > <https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7>* >
