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])
