Hi,
I''ve been using dynamic environments, one per Git branch, similar to
what''s described here:
http://puppetlabs.com/blog/git-workflow-and-puppet-environments/
I''ve come to really like that workflow, but I''m struggling
with how
best to integrate it with Hiera. In addition to short lived dynamic
branches, I''ll have some longer lived ones that feed into master
(production), e.g. staging, dev, etc.
My hierarchy has traditionally looked something like this:
- ''environments/%{environment}/%{location}'',
- ''environments/%{environment}'',
- ''global''
What''s the best way of having new environments pick data from the
right spot in the hierarchy without having to cram everything into the
global / common root?
For example, if I branch off of dev, creating a new environment called
''new_feature'', only ''global'' would be in
scope unless I explicitly
copy the dev data to ''new_feature.yaml'', which feels wrong.
Am I approaching this all wrong? Any advice?
--
Thanks,
Brad
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Hi Brad, On Tuesday, January 8, 2013 10:30:11 PM UTC, Brad Ison wrote:> > Hi, > > I''ve been using dynamic environments, one per Git branch, similar to > what''s described here: > > http://puppetlabs.com/blog/git-workflow-and-puppet-environments/ > > I''ve come to really like that workflow, but I''m struggling with how > best to integrate it with Hiera. In addition to short lived dynamic > branches, I''ll have some longer lived ones that feed into master > (production), e.g. staging, dev, etc. >I am using the very same workflow.> > My hierarchy has traditionally looked something like this: > > - ''environments/%{environment}/%{location}'', > - ''environments/%{environment}'', > - ''global'' > > What''s the best way of having new environments pick data from the > right spot in the hierarchy without having to cram everything into the > global / common root? >Your hierarchy data store is outside your environment, here is what mine looks like: :backends: - yaml :hierarchy: - %{fqdn} - %{role}_role - %{pop} - global :yaml: :datadir: /etc/puppet/environments/%{environment}/hiera/ So if I push a new feature to branch new_feature, I get Puppet environment "new_feature" which has it''s own copy of the Hiera data store with all my new_feature related Hiera keys in it. When it comes to environments my data follows the same branches and "versions" of my code, and when I merge code into my main line production branch the matching Hiera keys go along with it. Hope that helps, -Luke> For example, if I branch off of dev, creating a new environment called > ''new_feature'', only ''global'' would be in scope unless I explicitly > copy the dev data to ''new_feature.yaml'', which feels wrong. > > > Am I approaching this all wrong? Any advice? > > -- > Thanks, > Brad >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4d_axfRmI-QJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Jan 9, 2013 at 3:11 AM, Luke Bigum <Luke.Bigum@lmax.com> wrote:> > :backends: > - yaml > :hierarchy: > - %{fqdn} > - %{role}_role > - %{pop} > - global > :yaml: > :datadir: /etc/puppet/environments/%{environment}/hiera/ > > So if I push a new feature to branch new_feature, I get Puppet environment > "new_feature" which has it''s own copy of the Hiera data store with all my > new_feature related Hiera keys in it. When it comes to environments my data > follows the same branches and "versions" of my code, and when I merge code > into my main line production branch the matching Hiera keys go along with > it.Thanks, Luke. I guess it does make sense to leave the environments out of the hierarchy in this case. I had considered that, but was worried about constant merge conflicts when promoting things up the chain. There will be some things that will always be different between dev and prod. I suppose there are other ways around that though that make more sense. I may be inventing a problem I don''t really have. -- Brad -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I also use one environment per git branch. But I use a custom fact that returns production/testing etc and then use that in the hiera hierarchy instead of the puppet environment. On Jan 9, 2013 7:43 PM, "Brad Ison" <bison@oib.com> wrote:> On Wed, Jan 9, 2013 at 3:11 AM, Luke Bigum <Luke.Bigum@lmax.com> wrote: > > > > :backends: > > - yaml > > :hierarchy: > > - %{fqdn} > > - %{role}_role > > - %{pop} > > - global > > :yaml: > > :datadir: /etc/puppet/environments/%{environment}/hiera/ > > > > So if I push a new feature to branch new_feature, I get Puppet > environment > > "new_feature" which has it''s own copy of the Hiera data store with all my > > new_feature related Hiera keys in it. When it comes to environments my > data > > follows the same branches and "versions" of my code, and when I merge > code > > into my main line production branch the matching Hiera keys go along with > > it. > > Thanks, Luke. > > I guess it does make sense to leave the environments out of the > hierarchy in this case. I had considered that, but was worried about > constant merge conflicts when promoting things up the chain. There > will be some things that will always be different between dev and > prod. I suppose there are other ways around that though that make more > sense. I may be inventing a problem I don''t really have. > > -- > Brad > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, Jan 11, 2013 at 12:10 PM, Erik Dalén <erik.gustav.dalen@gmail.com> wrote:> I also use one environment per git branch. But I use a custom fact that > returns production/testing etc and then use that in the hiera hierarchy > instead of the puppet environment.That''s actually along the lines of what I was thinking originally. One Puppet environment per branch, remove the Puppet environment from the Hiera hierarchy, and have my ENC tag machines with which Hiera "environment" to use. Makes sense. Thanks! -- Brad -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.