Sending again -- earlier try bounced.
On Mon, May 19, 2014 at 10:25 AM, Brian Wickman <wick...@apache.org> wrote:
> Perhaps a stop-gap would be to require explicit aliases, e.g.
>
> [aliases]
> test-west = wickman/west/test/service
> test-east = wickman/east/test/service
> prod-west = wickman/west/test/service
> prod-east = wickman/east/test/service
>
> Alternately, if you wanted to be particularly advanced, you could do some
> sort of ad hoc job key templating, e.g.
>
> [templates]
> jobkey: {{environment}}-{{cluster}}
>
> The client would generate the mapping from jobkey template to jobkey by
> evaluating the template in the context of each job, accepting the alternate
> format provided there are no duplicates. Less thrilled about that approach
> but it does achieve the effect with minimal typing.
>
> ~brian
>
>
>
> On Mon, May 19, 2014 at 10:03 AM, Maxim Khutornenko <ma...@apache.org>wrote:
>
>> Perhaps it's just me but it feels that benefit/risk balance is weighted
>> heavily towards the risk side. The only time this feature is useful is
>> when
>> you have one job, one environment and one config file that never change.
>> That seem like a rare case. On the flip side, for anyone who has to switch
>> between different jobs/configs this feature is useless at the very least
>> or
>> even dangerous if used carelessly.
>>
>> I very much in favor of command shortcuts though as that would be a great
>> makeup for the increased verbosity of the client v2.
>>
>> Thanks,
>> Maxim
>>
>>
>> On Mon, May 19, 2014 at 9:42 AM, Mark Chu-Carroll <mchucarr...@apache.org
>> >wrote:
>>
>> > 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 <ma...@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 <
>> > mchucarr...@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.
>> > > >
>> > >
>> >
>>
>
>
