brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Turli <andrea.tu...@cloudsoftcorp.com>
Subject Re: Request for comment on a proposal for a Brooklyn CLI
Date Fri, 20 Nov 2015 14:32:02 GMT
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 <david.lloyd@cloudsoftcorp.com>
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 <
> svetoslav.neykov@cloudsoftcorp.com> 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 <
> > geoff.macartney@cloudsoftcorp.com> 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 <aled.sage@gmail.com> 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 (geoff.macartney@cloudsoft.io)
> > >>> David Lloyd (david.lloyd@cloudsoft.io)
> > >>>
> > >>
> > >
> >
> >
>

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