Do you use the same inventory for all of your playbooks? I'm not familiar with the change that made this pattern not work, but does it only pull in group_vars for groups in your inventory? If you used separate inventories for each environment would this problem go away?
On Wed, Nov 5, 2014 at 12:30 PM, Colin Nichols <[email protected]> wrote: >> Is this being done because some team members might leave the team later >> and no longer need access to something? > > > We have 3 vaults -- one each for dev, staging, and production. They contain > all the same variables, just with different values. We gave them all > different passwords so that our dev/staging playbooks can be deployed by > "untrusted" agents (untrusted relatively speaking -- e.g., CI server, > temporary contractors, etc.) without revealing production secrets. > > You can see why it might be confusing to me, then, to hear that ansible must > include all group_vars as a sort of insurance policy. I'm new to ansible, > and I haven't seen a project laid out any other way than what I've described > thus far. In this pattern, when the user runs the staging.yml playbook, > they do not need group_vars/production/*. Indeed it would be potentially > harmful if it were included, possibly resulting in broken configurations if > values from group_vars/staging/* were overwritten. > > It sounds like I'm not the only person using ansible in this way, and I find > it to be extremely convenient. I think it's a great solution for the > problem of managing secrets for multiple environments; certainly seems like > an issue that's in ansible's wheelhouse. > > If there's a more efficient way to deal with the problem of managing secrets > for multiple environments, I'd be interested in learning. I guess for now I > will convert to using var_files on all my plays. I view this as a subpar > solution, though, because it is considerably less maintainable. > > Is there a better way to solve my issue of secrets for multiple > environments, and if not would you consider reopening this as an issue, so > that the workflow I described can be used? > > Thanks, > Colin > > > On Tuesday, November 4, 2014 4:02:31 PM UTC-5, Michael DeHaan wrote: >> >> It's going to be the case because we don't know if a template will >> reference a variable later. >> >> >> >> >> On Tue, Nov 4, 2014 at 7:09 AM, Barry Morrison <[email protected]> wrote: >>> >>> This has been a paint point for our team as well, asking for a vault >>> password when the playbook has nothing to do with vaulted items. Wish this >>> weren't the case. >>> >>> >>> On Thursday, October 30, 2014 3:01:01 PM UTC-7, Colin Nichols wrote: >>>> >>>> Hi all, >>>> >>>> I've been using ansible 1.6.x and I love it -- soo much easier than how >>>> I've had to do things in the past :) >>>> >>>> I'm running into an issue upgrading to 1.7.x. Suddenly all my playbooks >>>> refuse to run; ansible errors out saying it needs my vault credentials. >>>> The >>>> output looks like this: >>>> >>>> xkillac4@MHK-01:~/project/ansible$ ansible-playbook unittest.yml >>>> ERROR: A vault password must be specified to decrypt >>>> /home/xkillac4/project/ansible/group_vars/vagrant/vault.yml >>>> xkillac4@MHK-01:~/project/ansible$ >>>> >>>> >>>> I feel like I may be missing something obvious, and would really >>>> appreciate it if someone took a look at my example below. >>>> >>>> I boiled the issue down into a toy project, and put it into tarball >>>> here: >>>> https://www.dropbox.com/s/gu2t7mymyeio838/ansible-testcase.tar.gz?dl=0 >>>> (or for the cautious, in a gist here: >>>> https://gist.github.com/c-nichols/aca08301235ddd5b4014 >>>> >>>> Why does my example error out? Is it expected behavior, given that I >>>> don't need anything from the vault and am not referencing any hosts from >>>> the >>>> group with the vault? Why does this example work with ansible prior to >>>> 1.7? >>>> >>>> What do you guys think? Am I missing something obvious? >>>> >>>> Thanks, >>>> Colin >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/c7f80063-6e17-4499-80dd-bb248294f36e%40googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/046a6ad2-80a1-4d74-821b-9385698b6b21%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJQqANcZQWLuYi%3DcTz-1B4r2V%3DO%2BhqFtsqisAoOLQ_58TJpOYA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
