Skip to content

Conversation

@cordu-dev
Copy link

Hi,

I have a use case where in some other jinja templates I reference these pillar data. So I need to have a steady key and the name should be different for each environment.

Do you think this PR makes sense?

e.g. postgres pillar for dev env:

  users:
    devices_user:
      name: dev_devices_user
      ensure: present
      password: 'password'

  databases:
    devices:
      name: dev_devices
      owner: 'dev_devices_user'
      template: 'template0'

e.g. postgres pillar for test env:

  users:
    devices_user:
      name: test_devices_user
      ensure: present
      password: 'password'

  databases:
    devices:
      name: test_devices
      owner: 'test_devices_user'
      template: 'template0'

e.g. a Jinja template that configures my Django databases for different envs:

DATABASES:
  default:
    ENGINE: 'django.db.backends.postgresql'
    NAME: '{{ salt.pillar.get('postgres:databases:devices:name') }}'
    USER: '{{ salt.pillar.get('postgres:users:devices_user:name') }}'
    PASSWORD: '{{ salt.pillar.get('postgres:users:devices_user:password') }}'

@johnkeates
Copy link
Contributor

Wouldn't this break existing setups? Also, aren't envs better used using Salt's own env support?

@cordu-dev
Copy link
Author

Well, I'm using the Salt's own env support. I don't really get it. I'm a bit new to this salt world :) My yamjam Django database config sits in a template and it's used in states to ensure my supervised gunicorn server will have the correct database config for each salt env.

Now It won't break the existing setup since there is entity.get('name') or key so if there is no name given, it will use the key.

Is there a better way of accomplishing what I'm looking for?

Copy link
Contributor

@vutny vutny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, we missed this PR in time, and it became outdated.

Now the same functionality is going to be covered by #223 . So this one could be closed. Thanks for your work @Lucianovici .

FYI @aboe76

@aboe76
Copy link
Contributor

aboe76 commented Jul 29, 2018

#223 is merged closing this one.

@aboe76 aboe76 closed this Jul 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants