Sceptre: Referencing more than sceptre_user_data in jinja2 template

Created on 24 Apr 2018  路  11Comments  路  Source: Sceptre/sceptre

I'd like to reference global variables in config.yaml such as "environment".

I don't want to have to duplicate these values in every single stack config file.

The docs suggest that other vars should be accessible via

sceptre.environment.Environment().config

https://sceptre.cloudreach.com/latest/docs/environment_config.html

Not sure exactly where this can be used though.

Also, I'd like to be able to reference, say, project_code in a jinja2 template. Can't seem to do that either.

Can you please look into exposing all variables to jinja2 templates?

Most helpful comment

I can confirm that @m1keil is correct, this issue has not been addressed in V2. Also {{ environment_config }} isn't available in V2 either so @et304383 workaround doesn't work in V2. My workaround for this issue is to create the sceptre-identity-resolver. This is still just a workaround, I agree with @et304383 comment: "I just want environment config to be available to all stacks without having to pass in to scepture user data".

All 11 comments

I have managed to work around this slightly by declaring a single variable in my stack config file that contains all the environment config values:

sceptre_user_data:
  environment_config: {{ environment_config }}

Then referencing by:

{{ sceptre_user_data.environment_config.project_code }}

@et304383 Did you resolve your issue? Are you happy for me to close this?

I guess my main problem is that in every stack config file I have to explicitly pass in the environment config.

It would be nice if it was just available like this:

{{ environment_config.project_code }}

Does https://github.com/cloudreach/sceptre/issues/256 describe the desired outcome?

I don't see how. I just want environment config to be available to all stacks without having to pass in to scepture user data.

Issue #256 does seem kind of related, but the namespaces/global-config/command-line stuff it is mentioning seems to propose extra conventions. What makes the most sense to me for this ticket is just putting both environment_config and stack_config in the jinja context if possible, because this actually makes existing conventions from jinja more symmetric with python resolvers / hooks.

Making environment_config available in the jinja2 context would be the most flexible.

I agree. It will be a lot cleaner if we can simply have access to environment_config in jinja2 template without having to explicitly adding sceptre_user_data section in stack config file.

This should be addressed in v2. Would anyone be willing to test on a simple setup?

I don't believe this is. Just looking at the Stack template() method:

    @property
    def template(self):
        """
        Returns the CloudFormation Template used to create the Stack.

        :returns: The Stack's template.
        :rtype: str
        """
        self.connection_manager = ConnectionManager(
            self.region, self.profile, self.external_name
        )
        if self._template is None:
            self._template = Template(
                path=self.template_path,
                sceptre_user_data=self.sceptre_user_data,
                s3_details=self.s3_details,
                connection_manager=self.connection_manager
            )
        return self._template

I believe that in order to provide solution here, we'll need to pass stack_group_config as well as numerous other variables from the stack object like name, project_code, region etc.

I can confirm that @m1keil is correct, this issue has not been addressed in V2. Also {{ environment_config }} isn't available in V2 either so @et304383 workaround doesn't work in V2. My workaround for this issue is to create the sceptre-identity-resolver. This is still just a workaround, I agree with @et304383 comment: "I just want environment config to be available to all stacks without having to pass in to scepture user data".

Was this page helpful?
0 / 5 - 0 ratings

Related issues

n2taylor picture n2taylor  路  7Comments

laur1s picture laur1s  路  4Comments

m1keil picture m1keil  路  6Comments

tahoward picture tahoward  路  4Comments

dalibor-aleksic-atomia picture dalibor-aleksic-atomia  路  4Comments