Ah, that's what I thought. Haha thanks 😄

Are you also switching from distro-provided to upstream-provided RPMs (or vice versa)? That kind of error smells like missing obsolence metadata in the package, which commonly happens if switching from one source of the packages to another

For Puppet, if you want to migrate up versions and you need to pin the version (like in a database, for instance) you can do something like:

package { 'foo':
  ensure => '1.2.4',
}

or even manage the packages in your repository, whether Yum or Spacewalk, or Satellite) and then just ask Puppet to put in the latest:

package { 'foo':
  ensure => 'latest',
}

Are you also switching from distro-provided to upstream-provided RPMs (or vice versa)? That kind of error smells like missing obsolence metadata in the package, which commonly happens if switching from one source of the packages to another

Yeah, I believe I am switching from the distro provided one.

I'll try adding the ensure=> '3.0.0' and see if that works.

so the root cause is more like there isn't a neat upgrade path from one provider of the packages to the other. the same content is provided in different package names after the switch, and the new provider isn't marking the packages used by the old provider as obsolete

so the root cause is more like there isn't a neat upgrade path from one provider of the packages to the other. the same content is provided in different package names after the switch, and the new provider isn't marking the packages used by the old provider as obsolete

you'll probably have to conditionally ensure the old packages are absent before the new packages are installed, where you want to upgrade

unfortunately, if you’re switching sources for your packaging, you might end up having to backup the database, remove the old packaging, point to the new repos, and then install and then import your data.

Yeah… what Ben said

yeah, this is probably off-piste and untested. you will want to test the upgrade process in a staging environment no matter what method you end up with!

yeah, this is probably off-piste and untested. you will want to test the upgrade process in a staging environment no matter what method you end up with!

Ah, that makes sense. Perhaps, just moving away from the distro one where I can only get to 2.6 is necessary. Thanks for all the info. I tested on a development server by uninstalling and letting puppet do the upgrade and everything went fine. It's a bit more scary uninstalling on a production server with actual data.

just make sure you have backups.

And make sure they’re re-loadable.

ensuring the old package is uninstalled is likely all you need to let puppet handle the upgrade in this case. if it's a VM and you can snapshot, do that first! 🙂

I can tell stories of clients who faithfully did their backups every day and rotated tapes and everything. Nobody told them to rotate out media, so they had multiple-years of dailies completely gone because they didn’t keep up with their media.

Yep, it's a VM, snapshot was taken a few hours ago. Time to upgrade. Thanks again for all the info. The repos are a bit confusing how they work.

Or, bootable backups (mksysb on AIX) that were completing, but for some reason the boot sector didn’t write, so they couldn’t recover from a crash

take two

Let’s just say I’m “risk averse”

Ok, will do. Having a restore fail would be the worst possible thing.

And the docs' release notes claim that Puppet 6.27.0 was never released, when Puppet 6.27.0 is what the 6.27.1 package delivers.

And the docs' release notes claim that Puppet 6.27.0 was never released, when the Puppet 6.27.0 release is what the 6.27.1 package delivers.

It got better when the package version started to reflect the Puppet version (most of the time) starting in 5.x

When AIO installers were first introduced with Puppet 4.x, they tried to explicitly different versions between packages and components, and the result was confusion. Without looking it up: which

puppet-agent

package provided Puppet 4.10.12? (That might be a bad example; @csharpsteen might be one of the few that will remember 😛

And that assumption is not bad―they ought to match, judging by other AIOs. For instance: Bolt is also packaged as an AIO. It even includes Puppet, but since the point of the package is to install Bolt + everything it needs, the package version reflects the version of Bolt.

Upgrade successful! Thank you @CVQuesty and @Ben Roberts 😄 Just had to do

yum remove mongodb

and

yum remove mongodb-server

then change some ownership of the directories to match the user running it and it's back running. Thanks again!!