Page MenuHomeClusterLabs Projects

Fix regression in crm_resource master resource handling
Open, HighPublic

Assigned To
Authored By
kgaillot
Mon, Sep 30, 10:31 AM
Tags
  • Restricted Project
  • Restricted Project
  • Restricted Project
  • Restricted Project
  • Restricted Project
Referenced Files
None
Subscribers

Description

crm_resource runs the scheduler to find resources, which upgrades the CIB to the latest schema. With recent changes, this means master elements are converted to clone elements. For options that modify the CIB, this means that crm_resource will try to modify the clone resource, which does not exist from the CIB's point of view.

crm_resource needs to use the original, non-upgraded resource configuration when making modifications.

Event Timeline

kgaillot created this task.
kgaillot created this object with edit policy "Restricted Project (Project)".
kgaillot added a project: Restricted Project.
kgaillot moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

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.
This comment was removed by nrwahl2.