sigdba / sig-shared-sceptre

Shared templates for Sceptre/CloudFormation
2 stars 0 forks source link

EcsWebService: Environment variable "sets" #70

Closed dboitnot closed 1 year ago

dboitnot commented 1 year ago

It would be useful if there was a way to define a "set" of environment variables (or secrets) in a config file and add them to a container's environment with one line. I think the easiest way to deal with this would be to change env_vars and secrets from Dict[str,str] to Union[Dict[str,str],List[Dict[str,str]]]. So in cases where we want to use a set, we could put something like the following in a config file:

saml_env_vars:
  metadata_url: https://whatever.school.edu
  logout_url: https://later-dude.school.edu

Then on the stack configuration:

env:
  - {{ saml_env_vars }}
  - some_other_var: some_value
    yet_another_var: another_value
dboitnot commented 1 year ago

While working on this I noticed we can get weird parsing issues with the YAML and I'm not sure what to do about it. For instance, with this in config.yaml:

env_var_set_2:
  evs_3: value_3
  evs_4: value_4

This works as expected:

      secrets:
        - {{ env_var_set_2 }}
        - evs_3: override3
          something: wild
        - test: west

But this:

      secrets:
        - {{ env_var_set_2 }}
        - evs_3: override3
          something: wild

Arrives at the validator as:

{'evs_3': 'something'}

By dumping the sceptre_user_data before handing it to Pydantic, I can see that it's not the YAML/Jinja2 parsing.

This turned out to be caused by an issue inside Pydantic's handling of the Union type. Switching the order of the Union types (Union[List[Dict[str, str]], Dict[str, str]]) seems to have fixed the issue.

dboitnot commented 1 year ago

Available as of release 108.