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
