Kotaimen / awscfncli

Friendly AWS CloudFormation CLI
MIT License
59 stars 12 forks source link

Allow for blueprints inheritance and multiple inheritance #58

Open mkielar opened 6 years ago

mkielar commented 6 years ago

Would you consider allowing Blueprints to extend each other? Would you consider allowing multiple inheritance of Blueprints?

That would create an multi-level inheritance model where one could have a Common blueprint with shared configuration, and then inherit from it to create blueprints that are dedicated, say to a specific region or environment.

E.g. if I have ~20 DynamoDB tables, and want to have different capacity on different environments, I could either extend the Common blueprint by only overriding capacity parameters, or I could create a separate Blueprint (a Mixin, really) with just the configuration for DynamoDB Capacity, and then, use both to extend the stack.

Kotaimen commented 6 years ago

Hi @GlieseRay:

I think he is asking for "OOP" version of Blueprints which is technically feasible. I wonder how much effort is needed to check the dependency graph...?

Kotaimen commented 6 years ago

Hi @mkielar:

I believe you can use YAMl tags to achieve similar effect:

account01: &account01
  Profile: foo

capacity01: &capacity01
  ReadCapacity: 10

BluePrints:
  BluePrint1:
    Template: foobar.yaml
    Parameters:
      Foo: bar

Stages:
  Dev:
    Stack1:
     <<: *account01
     Extends: BluePrint1
     Parameters:
       <<: capacity01
mkielar commented 5 years ago

I'll give it a try with yaml tags, however they seem to have different merging model to what python does with dicts (see here - haven't tried that yet, so not 100% sure, but if it is, this will not be consistent with how blueprints work).

I can prepare a pull request if you're OK with it, just let me know against which branch, as probably too big to go directly to master?

I'm also thinking that if we go with multiple inheritance approach (one stack, multiple blueprints), then inheritance of blueprints is not that much required, which, I think makes it easier. Then we'd only have to implement a case when the Extends can be a list, and the properties are applied in order of appearance in the Extends clause.

fisherpro commented 5 years ago

Bump. Would be great if we could get this enhancement merged.

Thank you.

fisherpro commented 5 years ago

Hi @mkielar:

I believe you can use YAMl tags to achieve similar effect:

I believe the proper term is YAML merge keys, not tags.