Closed by commit c6a8725f. Ping node support has not been dropped yet, but it will be soon.

This is actually only allowed by the pacemaker-next schema, so there's nothing to transform in the 3.10 to 4.0 upgrade. How do we want to go about this? I'm thinking just drop the Pacemaker code for it and leave the constraints-next schema alone until we drop pacemaker-next support altogether.

In T745#12714, @kgaillot wrote:

I've already got something ready to go

In T807#12633, @nrwahl2 wrote:

(with a little magic to re-allow the old name as a custom name after a CIB has been upgraded).

Do we want this immediately? This doesn't even require magic, it's the default behavior if we don't ban the old name in the new schema. However, last time we talked in Slack:

the idea is to prevent the newly dropped options from being used after the transform (at least until the next transform)
user has old CIB with dropped option: implicit upgrade drops the option
user has new CIB after option is dropped: can't add option
user has even newer CIB much later: can add dropped option as custom name
(schema major version X, X+1, X+2)

I've already got something ready to go

hope ya don't mind if I grab this one

Closed via cb298b9e. None of the commits from https://github.com/ClusterLabs/pacemaker/pull/3539 were properly linked here, despite their commit messages having the relevant phrases.

(with a little magic to re-allow the old name as a custom name after a CIB has been upgraded).

In T829#12444, @nrwahl2 wrote:

@kgaillot I had added this as a parent task because we can't drop require-all from ordering constraints until after we've dropped support for rolling upgrades from <2.0.0

@kgaillot I had added this as a parent task because we can't drop require-all from ordering constraints until after we've dropped support for rolling upgrades from <2.0.0