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 Wed, 25 Nov 2015 16:48:30 GMT
hello all,

following up on the earlier mail from David, to give a more concrete idea of what the CLI
would look like, we have created a first pass gist of how the new text of the Getting Started
would read [1].  This is based on the notes in the document linked below [2].   We hope that
this will serve two purposes, one, to give an outline of the changes required to the documents,
and, two, to give readers a clearer view of how the CLI would work in practice.  We invite
you to read and review the document, and will be very grateful for all feedback received.

The idea here is to do something quick and easy for everyone to read and comment on, so we
have put the whole thing into a one page gist.  It doesn’t include those parts of the Getting
Started that wouldn’t change (much), around installing Brooklyn, but covers the points in
David’s document:

Blueprints
	• Login
	• Launch an app from a Blueprint
	• List Applications

Managing
	• Entities
	• Summary
	• Sensors
	• Effectors

For the moment in the gist:

• as per the document, we have dropped the Catalog, Activities, and Policies, as we probably
need a bit more thought to create commands for these, for example the Catalog commands will
be replaced by Registry commands.
• the command is called “bk” rather than “br”
• we have ignored the issues of caching authentication details
• we have ignored the issue of how to ‘cache’ or ‘select’ the result of a command
so it can be implicit in subsequent commands, and/or any ability to create aliases.  As it
stands the commands require you to supply explicitly any IDs that are required.
• The intention is for commands to read from standard input where that can make sense, but
that’s not referred to in this first pass.

For completeness the references below include links to the original proposal document [3],
which includes more detail on some of those points that have been ignored in the gist at present,
and a Google spreadsheet with an overview of the commands [4] for ease of reference.

best regards
David and Geoff



[1] CLI-based-Getting-Started-Gist.md     https://gist.github.com/geomacy/b81952b859dbf8aaf4bf/
[2] CLI Impacts on Getting Started Guide https://docs.google.com/document/d/1Kat6J0S5eOd3SLd3zbLRb1VHBlCCeRpZKq-KlXQkb8E/
[3] Proposal for a Brooklyn CLI                 https://docs.google.com/document/d/1KNCHG--ExGevcGoJ3cRzcrjh3mWsZOzyCzRM_TpoGGo/
[4] Draft bk commands and features         https://docs.google.com/spreadsheets/d/1Skh5Uqrwg7I09DvXFgzbWL2wEmAP3tY1JEXrE4Eaeww/

————————————————————
Gnu PGP key - http://is.gd/TTTTuI


> On 25 Nov 2015, at 11:07, David Lloyd <david.lloyd@cloudsoftcorp.com> wrote:
> 
> 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