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
