inheretance behavior of `profile` overrides child with parent config about sceptre HOT 5 CLOSED

I am also noticing this inheritance issue related to project_code as well; in that the parent overrides the child.

from sceptre.

Hi Dan, I'm not sure how what you're experiencing is happening. I can say that we have several projects that override project_code in child configs (among other settings).

I would ask, however: Do you happen to have AWS environment variables set that might be directing your AWS environment to that profile (i.e. AWS_PROFILE environment variable, default profile on your aws config file, etc...)? Right now, if you explicitly specify a profile, Sceptre will use that. But if you do not specify a profile, Sceptre will use whatever your environment is set up to use. I can imagine scenarios where it may seem like the parent is overriding the child, but your specific AWS environment settings might be interfering.

from sceptre.

Ok I have more information. My original reproduction case wasn't detailed enough. consider this:

config/
|_ config.yaml
|_ shared.yaml
|_ /childconfig
    |_ sometemplate.yaml
    |_ config.yaml
templates/
|_ shared.yaml
|_ sometemplate.yaml

What's happening is that the resource creation for sometemplate.yaml is having all the inheritance from the child config applied to the config from the parent (/childconfig/config.yaml vs /config.yaml); the child one wins.

HOWEVER

shared.yaml does not have settings from /childconfig/config.yaml applied to config.yaml, even though my command specified to launch childconfig.

I suppose I might have a misunderstanding of how the inheritance works with StackGroup config. My expectation was that:

1. my project_code would be overridden for all stacks created, since I specified childconfig as a launch param.
2. The profile set in /childconfig/config.yaml would override for the entire process, but since I have a global stack config for one of my stacks, it wants to use the profile defined in the parent for it instead of using the one profile for the entire process.

I was hoping to be able to do something like change the project_code and profile used for the entire deployment based on the configuration I use at launch, not where the config exists in relation to where the template's config is defined. I wanted to keep the shared.yaml global, because all its doing is making a bucket, and its the same for every environment/configuration.

TL;DR: seems like StackGroup config and Stack config have a bit of a coupling issue?

Am I perhaps approaching this the wrong way, or is this more of a feature request than anything?

from sceptre.

Oh, what you've described is how Sceptre is supposed to work. shared.yaml shouldn't be affected at all by the StackConfig of /childconfig/config.yaml. Children don't change their aunts and uncles.

I would recommend one of the following:

• Set the profile in the parent config like like this: profile: {{var.profile}} and then you can run sceptre --var profile=dev launch ... and everything will get that profile
• Don't use a profile on your Stack Configs at all and instead just set the AWS_PROFILE environment variable before running Sceptre.

from sceptre.

I suppose that makes sense, although it does feel a bit weird that something like profile can't be globally overridden. Now that I understand the behavior though, I was able to get around it via the following:

1. setting the profile via variable like you suggested, and using default in cases where i dont want a specific profile
2. using a Jinja2 conditional to control the project_code based on the existence of another variable

for anyone who finds this via a search, it item 2 looks something like:

project_code: {% if var.owner is defined %} {{var.owner}}-some-service {% else %} someservice {% endif %}

Thanks for the help @jfalkenstein !

from sceptre.