On Fri, 20 Nov 2015 at 12:14 David Lloyd <[email protected]> wrote:
+1 Great idea. I will read the Google doc proposal in more depth when I have some more time. But, I have one suggestion that may be useful. Some possible commands that the CLI may provide include: > > br login > > cache login credentials for the Brooklyn instance > This works the way you expect, setting the context to a particular Brooklyn instance. br application cache <ID> > > cache the application <ID> to be used with subsequent commands that require > an application ID. > > 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). > 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
