Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
MIME-Version: 1.0
References: 
 <CAPqc3vfUgck0mbkcfAuhwgUEAkB_ZUk83h9rUf836fBm8YUHUg@mail.gmail.com>
 <CAEK0Ph2+-MKRmM=Gw5vEqz1K30N87vtbFYGzS4R3eO8NEvMUpA@mail.gmail.com>
In-Reply-To: 
 <CAEK0Ph2+-MKRmM=Gw5vEqz1K30N87vtbFYGzS4R3eO8NEvMUpA@mail.gmail.com>
From: Morgan Wright <morgan@cloudsoftcorp.com>
Date: Tue, 24 Nov 2015 14:27:29 +0000
Message-ID: 
 <CAJA+Y9H231+b44=wMVeyGf+eShoqWwf5FmTut0i43-abCiM0gA@mail.gmail.com>
Subject: Re: Request for comment on a proposal for a Brooklyn CLI
To: dev@brooklyn.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a1138f50ccbfb6005254a2469

--001a1138f50ccbfb6005254a2469
Content-Type: text/plain; charset=UTF-8

+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
>

--001a1138f50ccbfb6005254a2469--