aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "brian wickman (JIRA)" <>
Subject [jira] [Commented] (AURORA-915) create strict mode for .aurora config
Date Thu, 20 Nov 2014 17:22:33 GMT


brian wickman commented on AURORA-915:

[~tomdunham] actually no -- it's mostly used to introspect the job key, e.g.

# -*- python -*-
# Default production Mesos cluster configuration.

import sys

# Process
dc = sys.argv[4].split('/')[0]
environment = "staging"

Which is a terrible anti-pattern, for one since it ties you to a specific version / invocation
of the client, but also since this is usually available via the {{\{\{cluster\}\}}} template.

As part of AURORA-188, I think it does make sense to make -E more clearly supported.  Right
now it's sort of looked down upon since any context introduced by -E is lost when the job
is serialized on the client.  There are some mentions of how to not lose this context in AURORA-188.

> create strict mode for .aurora config
> -------------------------------------
>                 Key: AURORA-915
>                 URL:
>             Project: Aurora
>          Issue Type: Task
>          Components: Client
>            Reporter: brian wickman
> I propose we have a strict mode for .aurora configuration (pystachio) that prevents importing
python modules (including os and sys.)  Possibly we snapshot os.environ and provide a binding
helper to give access to it.  For people who need things like the current user, perhaps provide
a default binding like {{\{\{system.user\}\}}} and the like.  We are getting bitten by people
adding too much sophistication into .aurora configuration like full blown sys.args introspection
and web clients, etc.

This message was sent by Atlassian JIRA

View raw message