brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrew.kenn...@cloudsoftcorp.com>
Subject Re: Request for comment on a proposal for a Brooklyn CLI
Date Tue, 24 Nov 2015 17:08:00 GMT
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