There is a trend towards 2LAs (two-letter acronyms) for commands in
devops -- for instance `cf` and `tf` and of course `go`. We already
have `brooklyn` as a CLI for the *server*; however it does take a
`launch` argument so we could overload it:
brooklyn launch # launch a server on localhost (new
implementation as go command calling to some java)
brooklyn login URL # connect to a server somewhere
brooklyn list #
Though that is a bit confusing IMO. Or of course we could rename
existing bin/brooklyn as brooklyn-server, or go with broo.
Seems to me we have several options:
1) Use `br` for client operations and `brooklyn` for server (original
proposal)
2) Use `broo` for client operations and `brooklyn` for server (Svet's
proposal)
3) Use `brooklyn` for both server and client operations (Andrea's
proposal, expanded above)
4) Use `brooklyn` for client operations and `brooklyn-server` for server
operations (mod of Andrea's proposal)
I'm for "1" -- in my usage the 2LAs become very natural, and we're lucky
that `br` is not a known *nix command. (And I don't think there is that
much potential for confusion with the HTML tag.)
Best
Alex
On 20/11/2015 14:32, Andrea Turli wrote:
I agree with Svet, `br` sounds weird (too similar to <br> :) ) Why
`brooklyn` is not good? I think autocompletion will help and `brooklyn`
will be more mnemonic, maybe.
My minor comment,
Andrea
On Fri, 20 Nov 2015 at 14:28 David Lloyd <[email protected]>
wrote:
The existing CLI caches the login details (URL, username, password) in file
~/.brooklyn_cli, so I guess that we'll look initially at caching the other
IDs in this file.
Dave.
On 20 November 2015 at 13:18, Svetoslav Neykov <
[email protected]> wrote:
I see many of the commands using context (the cached entity). Where does
the context go into? Can parallel shells calling into the cli have
different contexts?
Perhaps we should keep the CLI context free and present the user with a
console for where context is needed (something similar to
http://htty.github.io/htty/)?
Personal preference to naming the executable broo.
+1 to having aliases for where context is allowed, but should be careful
with the lifetime of the aliases.
Svet.
On 20.11.2015 г., at 15:06, Geoff Macartney <
[email protected]> wrote:
Perhaps we could have an “alias” command for applications etc,
something
like
br application list
….// view the list of applications
br application alias myserver ID12ab
br application myserver add abc.yaml
br application myserver add def.yaml
br application myserver add xyz.yaml
————————————————————
Gnu PGP key - http://is.gd/TTTTuI
On 20 Nov 2015, at 12:59, Aled Sage <[email protected]> wrote:
Thanks,
This looks really good.
It will be great to have this, and to have a getting started guide
that
is based on this new CLI. Many other tools in the devops space focus on
this kind of client CLI (e.g. Docker, Cloud Foundry, etc).
---
I'm not sure about the "br application cache <ID>", which sets the app
id to be used for subsequent calls such as "br entity ...". If using IDs
they are globally unique, so we could just miss out the app id (we'd need
to add to the REST api to support that).
Would we want to support logical names for apps/entities, rather than
just IDs? The REST api supports looking up the app by its display name.
I'm
not convinced we want to do that, but it certainly is simple/useful
sometimes to use logical names.
Aled
On 20/11/2015 12:14, David Lloyd wrote:
Hi All,
We’ve been thinking that it would be really useful for Brooklyn to
have a
tool that provides a Command Line Interface (CLI) to augment the
current
web based GUI and REST API. The proposal below outlines what we are
thinking of. We request comments from the community on the idea, and
would
very much welcome suggestions for developing it.
Comments can be made by replying to this email or by adding
comment/suggestions to this document:
https://docs.google.com/document/d/1KNCHG--ExGevcGoJ3cRzcrjh3mWsZOzyCzRM_TpoGGo/edit?usp=sharing
(and there are two comments on the document already)
Description of Proposal
The current REST API provides a powerful way for controlling
Brooklyn,
but
it is difficult to combine operations (using the output of a command
as
input to a second command) using the GUI or using the REST API on a
command
line. We think that having a dedicated command line tool would make
it
easier for beginners and advanced users to control Brooklyn.
Robert Moss has already done some excellent work on the ‘Go CLI
client
for
Brooklyn REST API’ which can be found at
brooklyncentral/brooklyn-cli. Our
intention with this proposal would be to build upon this work and
implement
a set of commands that go beyond mirroring the REST API. We feel it
would
be best to keep the CLI in its own repo (so it can follow the Go
conventions), for example with the name brooklyn-cli.
We think that it is important for a CLI to be portable and to have as
few
(if any) dependencies on other tools as possible. Go has the
advantages of
compiling to native OS specific binaries that are statically linked,
so
avoids the need for installing dependencies (and getting the right
combination of versions!). It can also be compiled for multiple
operating
systems, enabling a CLI to be built for servers and typical end user
systems.
Some possible commands that the CLI may provide include:
br login
cache login credentials for the Brooklyn instance
br application list
show the list of applications
br application show <ID>
show details of application <ID>
br application cache <ID>
cache the application <ID> to be used with subsequent commands that
require
an application ID.
br application add <file|url>
add (deploy) the specified application blueprint
br entity list [-r]
list the entities for an application, recursively if ‘-r’ specified
(having previously used ‘br application cache <ID>’)
br entity show <ID>
show the details for an entity
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).
br sensor list
list the sensors for an application / entity
(having previously used ‘br application cache <ID>’ and ‘br entity
cache
<ID>’)
br sensor show <Name>
show the sensor value
br sensor show service.isUp
show the value of the service.isUp sensor on the previously specified
application / entity
br effector list
list the effectors for an application / entity
br effector invoke <Name> "{<parameter map>}"
run the effector <Name> for a previously cached application <ID> /
entity
<ID>
br catalog list
show the list of available catalog items
br catalog add <file|url>
add the specified catalog entries
br location list
list the available locations
br location show <ID>
show details for location <ID>
br location add "{locationSpec}"
add the specified location
It is intended that further commands would be added later such as:
-
br policy …
-
br activity …
-
etc.
Existing CLI
For reference the implemented commands for the existing brooklyn-cli
are:
USAGE:
br [global options] command [command options] [arguments...]
VERSION:
0.0.0
COMMANDS:
access Show access control
activity Show the activity for an entity
activity-children Show the child activities for an entity
activity-stream Show the stream for a given activity
add-catalog Add a new catalog item from the supplied YAML
add-children Add a child or children to this entity from the
supplied
YAML
application Show the status and location of a running application
applications Show the status and location of running applications
catalog List the available catalog applications
config Show the config for an application and entity
create Create a new brooklyn application from the supplied YAML
delete Delete a brooklyn application
destroy-policy Destroy a policy
effectors Show the list of effectors for an application and entity
entities Show the entites for an application
entity-children Show the children of an application's entity
locations List the available locations
login Login to brooklyn
policies Show the list of policies for an application and entity
policy Show the status of a policy for an application and entity
rename-entity Rename an entity
sensor Show the value of a sensor for an application and entity
sensors Show the sensors for an application and entity
set-config Set config for an entity
spec Get the YAML spec used to create the entity, if available
start-policy Start or resume a policy
stop-policy Suspends a policy
tree Show the tree of all applications
version Display the version of the connected Brooklyn
Geoff Macartney ([email protected])
David Lloyd ([email protected])
