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
