brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Macartney <geoff.macart...@cloudsoftcorp.com>
Subject Re: Request for comment on a proposal for a Brooklyn CLI
Date Tue, 24 Nov 2015 17:36:40 GMT
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 <andrew.kennedy@cloudsoftcorp.com> 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 <alex.heneveld@cloudsoftcorp.com>
> 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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message