This message was deleted.
# puppet-enterprise
s
This message was deleted.
b
why do you need different logic in the modules?
is that actually a requirement or do you only use it to set different default values
m
Maybe someone says that a server in production needs an additional file which the nonprod server does not
But yes you're right, we don't always need different logic and have modules with branches for production and nonprod just for the sake of it. I want to go away from this principle.
b
so from the perspective of one of your teams, they have a production environment with important systems and a non-prod environment with less important systems
but from a puppet point of view, that's not the case. you don't have the less-important env to test puppet code. it's used to test an application I guess? So puppet needs to work on both environments, it just does different things
is that roughly correct?
if so, I would not implement such an environment logic in the modules, but rather features flags like $manage_file_foo in the mentioned module. and you manage that parameter via hiera. it's true by default for nonprod and false for prod
that allows you to use the same branch/commit/tag of a module in both environments
and if that works you can think about if you actually need two puppet code environments
m
Yes that's correct! Interesting I haven't thought about this one yet. This might be something to consider. Oh and I totally left out Puppet profiles, which of course also have production and nonprod named branches just because.
b
think about if that's actually required or if it just makes stuff more confusing
m
Feature flags sound good, but I worry from knowing the people in my organization and the servers they run that this could get out of hand.
b
and now the branches dont get out of hand?
how often do you merge from one branch to another? how big is the gap between nonprod and prod?
most customers I support end up with two (or more) completely different environments over time because most of their stuff doesn't understand git enough to do merges/cherry-picks, so we try to reduce the git complecity
👍 1
m
Oh yes, it is absolutely confusing because you have servers which are to some IT teams "production" but actually run in the nonprod datacenter and are thus a nonprod system in the puppet environment but the module and profile are on a production branch. It's SO complicated that I want to just rip all this out. Disclaimer: I inherited this setup a couple years ago and am now rebuilding everything from the ground up
Yup, the people here also don't want to learn git and the ways on how to bring in changes etc. I'm happy if they do Pull Requests. But most just edit online on Bitbucket.
b
yeah rip it out 😄
on which puppet version are you
m
Regarding merging: We don't Because we have logic in each branch which cannot be brought over to the other because this would break the server
We'll be doing 7.24 with latest PE
b
okay
ah so if people want to implement something for both environments they have to do it twice?
m
Yes
b
ah well 😄
m
And then they forget to do it on the other branch
So I want to have logic in one branch where they can do exactly this in the SAME place so they don't have to think about it
They can still to PRs (which is good for reviews etc)
All this is a huge PITA and I hate everything about it 😄
b
I would try to get rid of the multiple branches and reduce that
m
Agreed. This is the first action I'm taking. The layer of complexity is too much and does not bring any benefits.
b
yep
in case you need and puppet or git training for the team, let me know 😄
m
Heh 😄 You say this so lightly
b
😄
m
Thanks for your feedback and input! 🙂
b
sure, your welcome
may I ask how many nodes you have? any performance issues?
m
Sure, so we have roughly 500 nodes and not really any performance issues. Why do you ask?
b
ah just curious. many people report performance problems
m
Interesting. Long run times or other things?
b
A mix of everything 😄
m
Ah nice 😄