brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Wright <mor...@cloudsoftcorp.com>
Subject Re: Request for comment on a proposal for a Brooklyn CLI
Date Tue, 24 Nov 2015 14:27:29 GMT
+1 for bk
On Tue, Nov 24, 2015 at 5:18 AM Andrew Kennedy <
andrew.kennedy@cloudsoftcorp.com> wrote:

> On Fri, 20 Nov 2015 at 12:14 David Lloyd <david.lloyd@cloudsoftcorp.com>
> 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
>

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