Hi All, We have put together a doc with some thoughts on how the new CLI may be incorporated into the Getting Started Guide, so that it covers the use of the CLI instead of the GUI: https://docs.google.com/document/d/1Kat6J0S5eOd3SLd3zbLRb1VHBlCCeRpZKq-KlXQkb8E/edit?usp=sharing
Please let us know what you think. Thanks, Dave. On 24 November 2015 at 17:36, Geoff Macartney < [email protected]> wrote: > hi Andrew > > I think that looks like something we’d at least leave until the rest of it > was mainly working. Perhaps a simple first step for ‘search’ type commands > like “list” would be supplying an argument that would be matched against > the display name - so > > br> application list > | ID | NAME | > | abc | clocker | > | def | mesos | > > br> application list mes > | ID | NAME | > | def | mesos | > > And if you did ‘application select mes’ it would select the application if > only one matched, as above, otherwise it would be just display possible > matches. > > Geoff > > > ———————————————————— > Gnu PGP key - http://is.gd/TTTTuI > > > > On 24 Nov 2015, at 17:08, Andrew Kennedy < > [email protected]> wrote: > > > > Agred. > > > > One thing we could perhaps implement is some kind of XPath syntax for a > > 'select' command. > > > > So '/123/**/456/child(2):sensor.name' would select the value of ' > sensor.name' > > on the second child of entity id 456 which is a descendant of the > > application id 123. Not sure if this is overly complex, though? Maybe its > > best to just go with ( app-id, entity-id ) pairs of ids (or names, or > > aliases) instead to uniquely specify an entity? > > > > Andrew. > > > > On Tue, 24 Nov 2015 at 17:00 Alex Heneveld < > [email protected]> > > wrote: > > > >> > >> karaf will make it easier to have this type of shell; its syntax should > >> mirror the CLI, but +1 Geoff that the CLI should be easily scriptable, > >> and installable, so the go approach is nice > >> > >> +1 Andrew that a single cross-shell "cached" entity is odd; the pure-ID > >> method is not too unusual (git, xen, etc), but it is irritating. > >> personally i like the concept of *aliases*; i like the idea of a > >> "*select*" command which can find items in a scope by name or by the > >> plan.id. i've updated section and comment at the end of [1] with some > >> ideas > >> > >> and belatedly +0 to "bk" over "br" -- we probably have to follow the > >> locals' lead (though i think this is more recent than my time there last > >> millenium) even if the sound of it is clumsier (i do still like the 2LA) > >> > >> best > >> alex > >> > >> [1] > >> > >> > https://docs.google.com/a/cloudsoftcorp.com/document/d/1fa9H88IgvZON709Xrano8gFp9YdPBx-1I5YDJurvM_g/edit?usp=sharing > >> > >> > >> On 24/11/2015 16:37, Geoff Macartney wrote: > >>> hi Andrew > >>> > >>> Thanks for the suggestion. We did in fact discuss something very much > >> on these lines yesterday morning. Our thoughts were basically > >>> > >>> - using a shell approach like this would be possible and would give you > >> the context that would let you remember the entities you are working > with > >> (‘cache’/’select’). > >>> - on the other hand that might make it harder to automate use of the > >> tool with a script, which is something we think would be important. > >>> - you could write the tool such that you could use it either in either > >> mode (as a command line tool or as a shell) but then you would want to > make > >> sure that anything you can do in the shell can just as easily be done in > >> the command line version, again for ease of use in automated scripts. > >>> - our provisional conclusion was that we’d avoid doing a shell based > >> approach for the moment and concentrate on making using it as a command > >> line tool as easy as possible. > >>> > >>> What do you think? > >>> > >>> regards > >>> Geoff > >>> > >>> > >>>> I get the idea behind these 'cache' commands, but they are a little > >>>> confusing, and probably not what you expect in a command line, where > >>>> commands should generally be idempotent, at least in terms of local > >> state, > >>>> and executable at any time, with the usual exception of login if > >> required. > >>>> What might be better is to leave the context out and make all CLI > >> commands > >>>> fully specified, and therefore repeatable in any context. Then, we > could > >>>> have a brooklyn 'shell' where there is a context, either global, > >>>> application or entity. You would specify commands without the 'br' > >> prefix. > >>>> A sample interaction might look like this: > >>>> > >>>> % brooklyn > >>>> br> login http://brooklyn.abstractvisitorpattern.co.uk:8081/ adk > >>>> password: hunter2 > >>>> br> application list > >>>> | ID | NAME | > >>>> | abc | clocker | > >>>> | def | mesos | > >>>> br> application select abc > >>>> br:clocker> entity list-children > >>>> | ID | NAME | > >>>> | ghi | docker-infrastructure | > >>>> br:clocker> entity select ghi > >>>> br:clocker: docker-infrastructure > entity list-children > >>>> | ID | NAME | > >>>> | jkl | docker-1 | > >>>> | mno | docker-2 | > >>>> | pqr | docker-3 | > >>>> | stu | calico-sdn | > >>>> br:clocker:docker-infrastructure> entity select mno > >>>> br:clocker:docker-2> sensor list > >>>> | NAME | TYPE | VALUE | > >>>> | cpu | Double | 0.25 | > >>>> | memory | Long | 8192000000 | > >>>> | containers | Integer | 2 | > >>>> br:clocker:docker-2> logout > >>>> > >>>> Note that we are selecting an application context, then an entity > >> context > >>>> in the _tree_ of entities, by id. Having an application/entity context > >>>> allows us to list current children, and show sensors on the current > >> entity > >>>> easily, and the context can be reported in the prompt for feedback. > >>>> > >>>> WDYT, assuming you aren't planning something like this already? > >>>> > >>>> Cheers, > >>>> Andrew. > >>>> > >>>> -- > >>>> > >>>> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > >>> > >> > >> -- > > > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > >
