brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lloyd <david.ll...@cloudsoftcorp.com>
Subject Re: Request for comment on a proposal for a Brooklyn CLI
Date Wed, 25 Nov 2015 11:07:51 GMT
Hi All,

We have put together a doc with some thoughts on how the new CLI may be
incorporated into the Getting Started Guide, so that it covers the use of
the CLI instead of the GUI:
https://docs.google.com/document/d/1Kat6J0S5eOd3SLd3zbLRb1VHBlCCeRpZKq-KlXQkb8E/edit?usp=sharing

Please let us know what you think.

Thanks,
Dave.

On 24 November 2015 at 17:36, Geoff Macartney <
geoff.macartney@cloudsoftcorp.com> wrote:

> 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