+1 For "bk" over "br" On 24 November 2015 at 09:41, Andrea Turli <[email protected]> wrote:
> +1 for `bk` > > On Tue, 24 Nov 2015 at 09:50 David Lloyd <[email protected]> > wrote: > > > +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>* > > > > > >
