brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lloyd <david.ll...@cloudsoftcorp.com>
Subject Re: Request for comment on a proposal for a Brooklyn CLI
Date Tue, 24 Nov 2015 08:50:27 GMT
+1 for option 1 style - but using Mike's suggestion of bk

On 24 November 2015 at 08:25, Mark McKenna <mark.mckenna@cloudsoftcorp.com>
wrote:

> +1 for option 1
> +1 For Mikes suggestion of "bk" over "br"
>
> On Tue, 24 Nov 2015, 00:12 Mike Zaccardo <mike.zaccardo@cloudsoftcorp.com>
> wrote:
>
> > +1 `brooklyn` for server
> > +1 2-letter command for client ops, but propose `bk` as the
> abbreviation[1]
> >
> > [1] That's how we New Yorkers do it
> >
> > On Mon, Nov 23, 2015 at 6:59 AM Aled Sage <aled.sage@gmail.com> wrote:
> >
> > > +1 for option (1): "br".
> > >
> > > If we're doing single transferable vote [1], then my second preference
> > > would be (3) with the understanding that the brooklyn server-side
> > > command may change substantially when we switch to Karaf. We should
> also
> > > be moving to using something like `service brooklyn start` for the
> > > server-side, so we could live with the name clash in the mean time.
> > >
> > > Aled
> > >
> > > [1] http://www.electoral-reform.org.uk/single-transferable-vote
> > >
> > >
> > > On 23/11/2015 11:45, Hadrian Zbarcea wrote:
> > > > I also like 'brooky' for some weird reason, but +1 for 'br'.
> > > >
> > > > Hadrian
> > > >
> > > > On 11/23/2015 04:26 AM, Alex Heneveld wrote:
> > > >>
> > > >> 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
> > > >>> <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)
> > > >>>>>>>>
> > > >>>>>
> > > >>
> > >
> > >
> >
> --
>
> *Mark McKenna*
>
> *Twitter :: @m4rkmckenna <https://twitter.com/m4rkmckenna>*
>
> *PGP :: public-key
> <https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7>*
>

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