aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Wickman <>
Subject Re: Inheritance in .aurora
Date Fri, 04 Apr 2014 22:45:15 GMT
Inheritance in pystachio is not pythonic, so what you're trying to do won't
work.  I consider this a broken window.  We've been discussing how to
improve this for a while in a backwards compatible fashion and will be
tracking ideas in an epic centered around
 What's likely to happen is that we move to a pattern where you create
Traits (Structs as they are today) and then compose them together with
combine()/extend() methods.  This would allow you to e.g. add new traits on
a Job object that are organization specific, like for example DockerImage.

A shorter term, easier-to-implement solution that has been discussed is to
add an .extend() method to Struct such that you could do something like the

class Profile(Struct):
  variable1 = String
  variable2 = Default(Integer, 5)

DerivedProfile = Profile.extend(
  variable2 = Default(Integer, 6),
  variable3 = Required(String))

so long as the derived attributes do not collide with types from the
parent, so as to maintain drop-in compatibility.  There are a lot of
drawbacks with this approach (complexity first and foremost) but it's worth
considering implementing.

In the meantime, you can always do something like:

class BaseProfile(Struct):
  jvm_ram_mb = Default(Integer, 512)
  jvm_flags = Default(String, '-Xmx{{jvm_ram_mb}} {{profile_name}}.conf')
  profile_name = Required(String)

DevProfile = BaseProfile(profile_name = 'dev')
ProdProfile = BaseProfile(profile_name = 'prod', jvm_ram_mb = 16384)
StagingProfile = ProdProfile(profile_name = 'staging')

And essentially achieve a similar effect, if not clean hierarchical


On Thu, Apr 3, 2014 at 8:34 PM, Anindya Sinha <>wrote:

> Hi
> I am playing around with .aurora files and am facing an issue when I am
> using a class hierarchy with the base class derived from Struct, as
> follows:
> The good case:
> class Profile(Struct):
>     environment = Required(String)
>     name = Default(String, 'test_app')
> PRODUCTION = Profile(environment = 'prod', name = 'my_profile_app')
> In this case, I have value populated in the following Mustache variables
> (which is fine):
> a) {{profile.environment}} = 'prod'
> b) {{}} = 'my_profile_app'
> Now, I add the following class that inherits from the base class Profile:
> class DerivedProfile(Profile):
>     mz_name = Default(String, 'my_derived_profile_app')
> and modify PRODUCTION as:
> PRODUCTION = DerivedProfile(environment = 'prod', name = 'my_profile_app')
> In this case, {{profile.mz_name}} is reported as invalid or as an"unbound
> variable" (output of aurora inspect below). Is this supported via Pystachio
> templating, ie. create a class hierarchy and ensure that I have access to
> the Mustache variables. Any quick pointers before I get into the details?
> My use case is that I want to have a base class with all my common
> attributes for all my apps, and a derived class for each app that handles
> app specific attributes.
> Thanks
> Anindya
> Following is output of aurora inspect:
> Traceback (most recent call last):
>   File
> "/usr/local/bin/aurora/.deps/",
> line 738, in _wrap_method
>     return_code = method()
>   File
> "/usr/local/bin/aurora/.deps/",
> line 760, in <lambda>
>     main = lambda: main_method(*args, **kwargs)
>   File "/usr/local/bin/aurora/apache/aurora/client/", line 74, in
> wrapped_function
>     return fn(*args)
>   File "/usr/local/bin/aurora/apache/aurora/client/commands/", line
> 273, in inspect
>     job_thrift = config.job()
>   File "/usr/local/bin/aurora/apache/aurora/config/", line 198,
> in job
>     raise self.InvalidConfig(str(e))
> InvalidConfig: The configuration was invalid: Config contains unbound
> variables: {{profile.mz_name}}

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