https://www.puppet.com/community logo
Join Slack
Powered by
This message was deleted.
# puppet
s
This message was deleted.
b
short version is: no
PuppetDB has an API, you can write a function to query a foreign PuppetDB and get information
or try to share one PuppetDB across the different puppetserver
or Upgrade the ancient puppet4 puppetserver
with "backup server" you mean a server that handles backups but has a puppet 4 agent that talks to a puppet 4 infra?
and now you've an additional puppet 7 infra?
j
yes to both
b
is there a reason for the puppet 4 infra? Why isn't the backup server using the new puppet infra?
l
or a reason why that data can't just live in hiera as a setting
instead of being a puppetdb query
b
nono, don't use hiera. then puppet 4 lives even longer 😄
l
lol I can't answer that one
I still have puppet 3 and 4
(not that i am anti-puppetdb query, but in this case it does at least allow you a migration path)
b
let me know if you need professional help 😄
l
I absolutely do, but not that a developer can provide 🤣
b
more like a therapist 😄
j
We were hoping to just replace our servers one by one and remove them over time from puppet4. It seemed like a big task. Feels bad when I say it out loud, probably because it is. But it's the path we're on atm. Okay, I have some answers.
b
What kind of stuff do you get from PuppetDB
l
so, the other thing is, if you migrate the p4 backup server to p7
the puppet 4 puppetdb will still have the data in it
as long as you don't remove the cert on the server minimally
but it is hackish, and the data does go away after some TTL
b
and you still need a function to get the data
l
yea, I am saying migrate the backup server, and then abuse the fact that puppetdb doesn't remove data quickly if at all
to query the old data in puppet4's pdb
b
and how do you query it?
j
sounds like we're going to have to build some kind of bridge no matter what, and it's probably going to be at least a little bit hackish.
l
puppetdb_query in both instances, the data is not updated in p4 anymore, but it still exists
b
but then you need to run puppet twice on the backup node, onces against p7 and once against p4
and ensure that both runs don't purge the configs from the other run
I would try to connect the puppet4 puppetserver to the puppet7 puppetdb
l
I agree with that
b
or stop the puppet agent on the backup node until the migration is done
l
and you can basically hard cut it over
because it will repopulate itself after the first run
and so if you migrated the pdb server and then run puppet on the backup server
it should repopulate before anyone hits it
b
or test all the puppet code with --noop and then move all servers to the new infra in a single change, and not one server after another
(or test with real tests, whatever)
l
but I absolutely feel you
I'm in the same mess here
b
dito. had to do that dance with multiple customers
j
We've been trying to cleanup some of the old things we did on puppet 3 and 4, so we weren't planning to copy most of the modules, but maybe I could make an environment for the old servers and move all the servers to puppet7 infra and then the old modules/puppet4 is completely removed when we update the OS. At that point, everything is in the same puppetdb. Not sure if this is better or worse than any of the other ideas.
b
sounds fine to me
and updating the code so it works with puppet 4 and puppet7 is possible
j
Thanks for the suggestions
b
sure. if you need more input or run into weird issues , or need a consultant ,just ask here 😄
a
When I was doing a 4 to 6 migration I built a separate puppet 6 server infrastructure and setup an additional noop cron job run on all my agents pointing to it. This was to seed the puppetdb and then check for any changes the agents thought they wanted to make.
Got to upgrade to 7 now, but I think a puppetdb 7 will ‘work’ with puppetserver 6 ok.
b
yeah 6 and 7 work together
a
Cool. Both ways? Ie does it matter which I upgrade first?
b
when they are on different servers it's a nobrainer
if it's the same server there were some weird rpm dependency problems. almost like Puppet doesn't want you to mix major versions!
a
Different servers, but I could choose to upgrade the puppetservers first, or what I’m more inclined to do is upgrade the puppetdb servers first instead.
b
you want to go to 7 or directly to 8?
a
I’m of the opinion that it should always be possible to have puppetdb one major version ahead of puppetserver. (Maybe with some caveats like you have to be running the latest eg. 6.x puppetserver if you want it to work with a 7.x puppetdb)
b
yeah
a
Almost certainly 7 first.
b
makes upgrades more smooth
a
No big bang changes if possible is the rule.
Open in Slack
PreviousNext
Powered by