basemodulepath helps here:
https://docs.puppet.com/puppet/latest/reference/configuration.html#basemodulepath
In puppet.conf:
basemodulepath = /etc/puppetlabs/code/environments/common/modules
If there's something that environments don't need to track specially (ntp and
mcollective modules come to mind), they can leave those out of their Puppetfile
and the common versions will be used.
That common branch has a puppetfile and the hiera hierarchy has
'common/hieradata/common' at the bottom. It hasn't eliminated the issue of
people's environments falling behind in specific areas. Whether that's an issue
depends greatly how you handle updates without a pressing platform need. There
are several positions on this matter held within this company so the hybrid
approach seems to be the least-worst solution.
(You should probably pick a better solution.)
Editorially: As to whether it's more or less painful to have 50 individual
operating environments I think we're in a bit of the same position.
Organizationally entrenched silos and decades-old practices mean we're handling
it in puppet instead of getting better answers to impertinent questions ("how
do these silos benefit the company's bottom line?"). There's only so much
curation we can automate away with that sort of headwind.
On Sat, Aug 20, 2016 at 01:52:31PM -0400, Chadwick Banning wrote:
> Can you explain more? When you say "Having a common environment for the
> common modules" that sounds like you would need to apply multiple puppet
> environments to a node to get the full config...one "common" environment
> and one with "non-common" configuration...and I don't think this is
> currently possible?
>
> On Aug 20, 2016 12:20 PM, "Christopher Wood"
> <[1]christopher_w...@pobox.com> wrote:
>
> Lots about hiera data in this thread, how about modules? Having a common
> environment for the common modules and using basemodulepath helps some,
> but it's not everything.
> On Sat, Aug 20, 2016 at 05:50:12AM -0700, Chadwick Banning wrote:
> > This is an issue I run into pretty regularly. If your Puppet
> > infrastructure is even moderately complex, I'd recommend NOT
> equating a
> > Puppet environment to an operational environment, operational
> environment
> > being the groups of machines known as dev, qa, staging, etc.
> > For instance, in my infrastructure we have 50+ different
> operational
> > environments. If I equate each one of these to a Puppet
> environment, I'd
> > need 50+ branches. While doable, this immediately becomes a
> nightmare if I
> > have a change that applies to all or some of the operational
> environments
> > -- say, changing something in my base profile. Now I have to a)
> hope all
> > 50+ branches are somewhat in sync, and b) merge my change into
> *each*
> > branch 50+ times. If the branches aren't in sync at all I very well
> might
> > end up having to fix unique conflicts each time I merge.
> > This is *not* a place where you want to end up.
> >
> > On Wednesday, August 17, 2016 at 4:21:45 PM UTC-4, Mike Sharpton
> wrote:
> >
> > Hey all,
> > We are coming up on an issue in our environment in where we have
> > multiple Puppet environments that are backed by git branches in a
> puppet
> > control repo. Our Hiera data is stored inside these branches and
> > changed frequently by our Operations teams. Of which we then
> have them
> > merge changes up the environment chain and r10k through our
> Puppet
> > environments. This is all fine.
> > Ex, dev -> test -> production, hiera data changes are moved up
> and
> > tested each step of the way.
> > When things aren't fine is when we are testing code in our dev or
> test
> > branch and we have changed the tags for modules/repos inside the
> > Puppetfile of those branches that we don't want in production
> right away
> > (dev/test). This code only applies to dev environment, on
> purpose.
> > Our operations team then comes along with their hiera changes and
> merges
> > the puppetfile module/repo changes up the chain along with the
> hiera
> > data. Effectively moving our Puppetfile changes up the chain
> when we
> > don't want to. We have thought about splitting hiera data out
> our
> > puppet control module like it was before Puppet 4, but this
> leaves us no
> > room to test hiera data up our environment chain and also leaves
> us with
> > some CI work to make this feasible. Having the hieradata in each
> > environment is too nice. We also attempted to monkey with
> .gitignore,
> > but this is not meant to do what we are trying to do. Don't
> merge
> > Puppetfile unless I want to.
> > Has anyone ran into this and found a somewhat elegant solution?
> > Everything we are coming up with is either not easy to manage,
> or just
> > doesn't make sense to do. Perhaps we are missing something
> simple and
> > are over thinking things. Thanks in advance.
> > Mike
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an
> > email to [1][2]puppet-users+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> >
>
> [2][3]https://groups.google.com/d/msgid/puppet-users/8abde89d-dfec-486e-b0ba-7ced6b6e07d8%40googlegroups.com.
> > For more options, visit [3][4]https://groups.google.com/d/optout.
> >
> > References
> >
> > Visible links
> > 1. mailto:[5]puppet-users+unsubscr...@googlegroups.com
> > 2.
>
> [6]https://groups.google.com/d/msgid/puppet-users/8abde89d-dfec-486e-b0ba-7ced6b6e07d8%40googlegroups.com?utm_medium=email&utm_source=footer
> > 3. [7]https://groups.google.com/d/optout
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
>
> [8]https://groups.google.com/d/topic/puppet-users/4YL6D4wwJww/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [9]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [10]https://groups.google.com/d/msgid/puppet-users/20160820161935.GB18127%40iniquitous.heresiarch.ca.
> For more options, visit [11]https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [12]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [13]https://groups.google.com/d/msgid/puppet-users/CAPwwW9G9o58-U0EBzJZhrZm6gp1tX8_oX0C-VBANF%3DWZw7jJnQ%40mail.gmail.com.
> For more options, visit [14]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:christopher_w...@pobox.com
> 2. mailto:puppet-users%2bunsubscr...@googlegroups.com
> 3.
> https://groups.google.com/d/msgid/puppet-users/8abde89d-dfec-486e-b0ba-7ced6b6e07d8%40googlegroups.com
> 4. https://groups.google.com/d/optout
> 5. mailto:puppet-users%2bunsubscr...@googlegroups.com
> 6.
> https://groups.google.com/d/msgid/puppet-users/8abde89d-dfec-486e-b0ba-7ced6b6e07d8%40googlegroups.com?utm_medium=email&utm_source=footer
> 7. https://groups.google.com/d/optout
> 8. https://groups.google.com/d/topic/puppet-users/4YL6D4wwJww/unsubscribe
> 9. mailto:puppet-users%2bunsubscr...@googlegroups.com
> 10.
> https://groups.google.com/d/msgid/puppet-users/20160820161935.GB18127%40iniquitous.heresiarch.ca
> 11. https://groups.google.com/d/optout
> 12. mailto:puppet-users+unsubscr...@googlegroups.com
> 13.
> https://groups.google.com/d/msgid/puppet-users/CAPwwW9G9o58-U0EBzJZhrZm6gp1tX8_oX0C-VBANF%3DWZw7jJnQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> 14. https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20160822134500.GA6208%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
