Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variable is undefined #813

Closed
fabiodouek opened this issue Aug 19, 2019 · 5 comments
Closed

Variable is undefined #813

fabiodouek opened this issue Aug 19, 2019 · 5 comments

Comments

@fabiodouek
Copy link

fabiodouek commented Aug 19, 2019

When defining the same variable in the config.yaml in different levels, causes Sceptre to intermittently return an error: <VARIABLE_NAME> is undefined.
Usually if I run again it works, but sometimes I have to run a few times. This is in the scope of creating a changeset.

e.g of structure
-config

  • dev
    • config.yaml (variable : x: a)
    • appb
      • config.yaml (variable : x: b)

The error is happening in Sceptre 2.1.0 and 2.1.5 (I havent' tested other versions, but I don't see this issue reported nor fixed in 2.2.0).

@marcoswerneckie
Copy link

This problem has often occurred continuously, and rerun has been the only immediate solution but sometimes it is necessary to rerun many times until it works.

@fabiodouek
Copy link
Author

fabiodouek commented Aug 31, 2019

The issue was due to variables referenced in a config.yaml from a top-level config.yaml. I understand that this feature is not supported in Sceptre (which would be a useful feature), but somehow in 30% of the cases was working. I removed those references for now, and the problem got resolved.

@ngfgrant
Copy link
Contributor

Is the issue to make the documentation clearer about this specific issue?

@carterdanko
Copy link

We have also run into this same issue trying to specify certain variables in the config.yaml for a particular region, but then in some stack_configs lower in the directory either updating vars or adding new vars.

aws_account
│   config.yaml
│
└───aws_service
│   │   stack_config.yaml

Where in this case we may define vars in the config.yaml as

central_vars:
  key1: true
  key2: false

And in stack_config.yaml, we may need to update or add to that base vars

stack_name: stack-name
template_path: path/to/template
{% set _ = central_vars.update({"key2" : "dummy_value"}) %}
sceptre_user_data:
  input_vars: {{ central_vars }}

@nathan-williams-rozettatechnology

I think this is related to #937

When rendering config files, Sceptre caches values across stack groups.
The "undefined" you are getting is the correct response, when it "works" it is actually using a value from one of your other config files.

The inconsistency between runs comes from Sceptre using a set to process the config files.
(Sets are non-deterministic in Python).

lucasvieirasilva added a commit to lucasvieirasilva/sceptre that referenced this issue Aug 17, 2021
mrowlingfox pushed a commit to fsa-streamotion/sceptre that referenced this issue Sep 21, 2021
This PR fixes nested `config.yaml` jinja substitutions (e.g `{{ someKey }}`).

Fixes issue: Sceptre#813

#### Scenario

Currently, when the project structure has multiple nested config files and one of them tries to use a property from another config file sometimes works, and sometimes not, when not work the error message is `<prop> is undefined.`.

Example structure:

```text
root/
  config/
    prod/
      A.yaml
      config.yaml
      2/
        B.yaml
        config.yaml
        3/
          C.yaml
          config.yaml
```

`config/prod/config.yaml`
```yaml
keyA: A
```

`config/prod/2/config.yaml`
```yaml
keyB: {{ keyA }}-B
```

`config/prod/2/3/config.yaml`
```yaml
keyA: {{ keyB }}-C
```

`keyB` should render the value `A-B` and `keyC` should render the value `A-B-C`

When running `sceptre launch prod` command the `ConfigReader` class doesn't follow a correct order to process the files, and sometimes the config object already has all the properties, sometimes not.

#### Solution

Sceptre already has a concept of recursive read in the `ConfigReader` class that reads all the `config.yaml` files recursively based on the parent path, and already has the config `dict` object with all the properties in the correct place, but when call the `_render` function just pass the `stack_group_config` that only contains the processed `stack_group_config`, which is fine when the files follow the correct order to be processed.

However, if the `ConfigReader` combines the current recursive object with the `stack_group_config` the `_render` will have all the required properties, doesn't matter which file order will be used to process the stacks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants