# Best Practices for dealing with multiple related sets of properties?

**URL:** <https://forum.ansible.com/t/best-practices-for-dealing-with-multiple-related-sets-of-properties/18003>\
**Category:** Ansible Project\
**Created:** [April 17, 2015, 9:54am UTC](https://forum.ansible.com/t/best-practices-for-dealing-with-multiple-related-sets-of-properties/18003 "2015-04-17T09:54:16Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Brad\_Smith](https://avatars.discourse-cdn.com/v4/letter/b/a587f6/32.png) [@Brad\_Smith](https://forum.ansible.com/u/Brad_Smith)\
**Post date:** [April 17, 2015, 9:54am UTC](https://forum.ansible.com/t/best-practices-for-dealing-with-multiple-related-sets-of-properties/18003/1 "2015-04-17T09:54:16Z")

</div>

Hello all,

Suppose I want to deploy multiple versions of a service (let’s call them v1 and v2, though they could also be different services with the same setup steps) to two environments (dev and prod). Since steps to deploy each version of the service are pretty much the same a single role should be able to handle both, except for some settings that can vary by version and environment, like which db host to use.

My first instinct here is to store the settings in a hash with the version numbers as keys, and then pass e.g. someservice\_config.v1 to the role, but it seems that Michael DeHaan [feels very strongly](https://groups.google.com/forum/#!topic/ansible-project/1f8Y1JCkwvI) that overriding individual dict values in the way I would need to make that work for dev/prod is Bad, and I really don’t want to have to redefine a whole hash just to change one or two values, so I’m trying to use flat vars like this:

`

## roles/someservice/defaults/main.yml

# Defaults

someservice\_deft\_db\_host: db1  
someservice\_deft\_db\_name: service  
someservice\_deft\_db\_user: some\_user  
someservice\_deft\_db\_pass: some\_pass

# v1-specific; mostly inherits defaults

someservice\_v1\_enabled: true

# v2-specific; different server and db name

someservice\_v2\_enabled: false  
someservice\_v2\_db\_host: db2  
someservice\_v2\_db\_name: servicev2  
`

`

## group\_vars/dev.yml

# Dev servers run both versions, with a different database for v2

someservice\_v2\_enabled: true  
someservice\_v2\_db\_host: db2-dev

## Nothing special in group\_vars/prod.yml, meaning prod servers

## inherit defaults and only deploy v1 with standard config (for now).

`

Ok, now I need to tell the role which set(s) of settings to use. The best I’ve been able to come up with so far is:

`

## main\_playbook.yml

- roles:

# Version 1

- role: someservice  
db\_name: “{{ someservice\_v1\_db\_name| default(someservice\_deft\_db\_name) }}”  
db\_host: “{{ someservice\_v1\_db\_host| default(someservice\_deft\_db\_host) }}”  
db\_user: “{{ someservice\_v1\_db\_user| default(someservice\_deft\_db\_user) }}”  
db\_pass: “{{ someservice\_v1\_db\_pass| default(someservice\_deft\_db\_pass) }}”  
when: someservice\_v1\_enabled

# Version 2

- role: someservice  
db\_name: “{{ someservice\_v2\_db\_name| default(someservice\_deft\_db\_name) }}”  
db\_host: “{{ someservice\_v2\_db\_host| default(someservice\_deft\_db\_host) }}”  
db\_user: “{{ someservice\_v2\_db\_user| default(someservice\_deft\_db\_user) }}”  
db\_pass: “{{ someservice\_v2\_db\_pass| default(someservice\_deft\_db\_pass) }}”  
when: someservice\_v2\_enabled

# Copy/paste + search/replace as needed for future versions…

`

`

## roles/someservice/tasks/main.yml

- mysql\_db: \>  
name: {{ db\_name }}  
login\_host: {{ db\_host }}  
login\_user: {{ db\_user }}  
login\_password: {{ db\_pass }}

# … and so on

`

This approach seems to work, but feels… klunky to me, so I figured I’d come here and ask for a sanity check. Is there a better way to approach this sort of thing?

Thanks!  
–Brad