aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Chu-Carroll <mchucarr...@apache.org>
Subject Re: Adding shorthands, defaults, and initialization files to the aurora client
Date Mon, 19 May 2014 16:42:03 GMT
I'd really hate to start hard-wiring special cases for certain commands
into the client. It seems like this a reasonable place to use hooks - you
can either create deployment-wide built-in hooks or project hooks to block
it.

The hook is going to get both the context object containing the processed
parameters, and the bare argument list that was passed on the command line.
It's easy to build a hook an kill/killall that says "If the parameters
aren't in the bare argument list, then abort".

   -Mark


On Mon, May 19, 2014 at 12:06 PM, Maxim Khutornenko <maxim@apache.org>wrote:

> Then, if the user ran "`aurora job create`" without any parameters,
> > it would automatically be expanded to
> > "`aurora job create west/markcc/test/myservice
> > ./src/aurora/myservice.aurora`".
>
>
> The power of this feature is a bit worrying. It's very easy to forget what
> init file defaults to. At the very least, I would not suggest supporting
> kill/killall command defaults.
>
>
>
> On Mon, May 19, 2014 at 8:44 AM, Mark Chu-Carroll <mchucarroll@apache.org
> >wrote:
>
> > Folks:
> >
> > Now that clientv2 is approaching stability, I'd like to start making some
> > usability changes. These are completely backwards compatible, but they're
> > intended to make the most common ways of using the aurora client more
> > convenient for users, without making any use-cases more difficult.
> >
> > A proposal for how to do this is below. Comments are not just welcome but
> > required!
> >
> > Thanks!
> >
> >       -Mark
> >
> > # Shorthands in the Aurora Client
> >
> > Most of the time, users are doing the same thing, over and over again.
> > They're working mainly on one particular service, in one particular
> > workspace. But they need to repeat the same parameters, over and over
> > again.
> >
> > To reduce this, we'd like to support a set of mechanisms for creating
> > shorthands and defaults. In this document, I propose what kinds of
> > shorthands - both standard, and user customizable - that we can
> > implement in the aurora client.
> >
> > ## Standard Shortcuts
> >
> > To save typing, we'll add _automatic_ shorthand generation to
> > the command-line framework. For nouns and verbs, any unambiguous
> > prefix of the appropriate word will be automatically expanded to
> > the full word.
> >
> >    * `aurora j c` will be expanded to `aurora job create`.
> >    * `aurora con l` will be expanded to `aurora config list`.
> >
> > ## User Customizations
> >
> > To allow users to customize shorthands, we'll provide a
> > builtin capability to allow users to provide a configuration
> > file, from which their customizations will be loaded.
> > Many applications use a simple pattern to solve similar problems.
> > Vagrant uses a file named "Vagrantfile"; when you run vagrant, if you
> > don't specifically tell the tool where to find a configuration, it looks
> > in the current directory or one of its parents to find a file named
> > "Vagrantfile".
> >
> > We'd like to follow a similar pattern, and create an "AuroraInit" file.
> >
> > ### What goes into an init file?
> >
> > Defaults and aliases.
> >
> > A default specifies a set of _bindings_. If a parameter is omitted
> > from a command, and there's a binding for that parameter, it will be
> > automatically inserted into the command as if the user had typed it.
> >
> > An alias is a short equivalent for a parameter. When a command line is
> > provided by a user, aliases will be expanded inline.  A user can
> > specifically
> > mark an alias for expansion by prefixing it with "@"; if an alias
> > appears on the command-line surrounded by whitespace, it will be
> > replaced even if it isn't marked with an "@".
> >
> > For example, an init file could contain the following:
> >
> >     init=Init(
> >       defaults={
> >         "jobspec": "west/markcc/test/myservice",
> >         "config_file": "./src/aurora/myservice.aurora"
> >       },
> >       aliases={
> >         "east": "east/markcc/test/myservice",
> >         "c": "east",
> >         "me": "markchucarroll"
> >       })
> >
> >
> > Then, if the user ran "`aurora job create`" without any parameters,
> > it would automatically be expanded to
> > "`aurora job create west/markcc/test/myservice
> > ./src/aurora/myservice.aurora`".
> >
> > If a user ran "`aurora job create east`", the alias `east` would be
> > expanded to "east/markcc/test/myservice", and the missing config file
> > parameter would
> > be instantiated using the default, to create a command-line:
> > "`aurora job create east/markcc/test/myservice
> > ./src/aurora/myservice.aurora`".
> >
> > If a user ran "aurora create @c/@me/test/myservice", the two aliases
> would
> > be expanded, and the omitted configuration parameter would be added:
> > "`aurora job create east/markchucarroll/test/myservice
> > ./src/aurora/myservice.aurora`".
> >
> >
> > ### Config Files
> >
> > The aurora client will look for a configuration file in the following
> > locations, in order:
> >
> >    1. A file named "AuroraInit" in the current directory.
> >    2. A file named "AuroraInit" in the sequence of parent directories of
> > the
> >      current directory up to the nearest repository root.
> >    3. A file named ".aurora" in the user's home directory.
> >
> >
> > Like most other files loaded by the aurora client (job configuration
> files,
> > hook files), the init file is a Pystachio configuration. It uses the
> > following schema:
> >
> >     class Init(Struct):
> >       defaults=Map(String, String)
> >       aliases=Map(String, String)
> >
> > The configuration defined by an init file is the object of type `Init`
> > that is assigned to the variable `init` in the init file.
> >
>

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