I wonder what would be the downside of doing the upgrade and writing it, so that the clone resource *does* exist from the CIB's point of view. It seems like keeping the old CIB around is a liability if anything.

In T885#14030, @nrwahl2 wrote:

I wonder what would be the downside of doing the upgrade and writing it, so that the clone resource *does* exist from the CIB's point of view. It seems like keeping the old CIB around is a liability if anything.

That would be a major change in Pacemaker's design. Currently we avoid modifying the configuration without being asked by the user (with a few exceptions of course). We've always required cibadmin --upgrade to upgrade the on-disk CIB.

There are arguments for automatically upgrading on disk, but the arguments for requiring user action are:

• Upgrade transforms can lose information (like dropping legacy resource types and options).
• Some users create configurations using tools like ansible, which might overwrite any automatically upgraded configuration.
• Transforms can go wrong, so it's best if the user can backup the configuration before upgrading.
• Mixed-version clusters would need to keep the old CIB around anyway until the last node is upgraded.
• Saved CIB files definitely shouldn't be automatically upgraded, so the current behavior would need to be maintained for that case anyway.