@nrwahl2 , that's part of T727

@kgaillot I don't think the existing XSLT error handler sets config warning, FYI. If we want that, we'll want a wishlist task for it, because it looks like it's gonna require some rearranging of cib_upgrade_err() that might be tricky to avoid redundant logs.

In T898#14811, @nrwahl2 wrote:

In T898#14801, @kgaillot wrote:

Since the risk of corner cases is so high, and our time for 3.0.0 is limited, I think the best approach would be to log a warning if a CIB contains ACLs with xpaths and the upgrade adds or renames any element or attribute. (We could possibly check whether an xpath exists that refers to an attribute, to reduce the scope a bit.) Something like: "WARNING: CIB syntax changes may invalidate ACLs that use 'xpath'. It is strongly recommended to run 'cibadmin --upgrade' then go through the updated CIB carefully to ensure ACLs still match the desired intent."

I'd also be fine with warning at the end if any ACLs use xpath, period. It's broader scope than necessary, but it avoids the need to clutter the stylesheet and the logs with individual warnings for each relevant transformation. (We could some of the log clutter by having one warning per step in the pipeline, but that may be a gnarly template to catch every case in a single template.)

In T898#14801, @kgaillot wrote:

Since the risk of corner cases is so high, and our time for 3.0.0 is limited, I think the best approach would be to log a warning if a CIB contains ACLs with xpaths and the upgrade adds or renames any element or attribute. (We could possibly check whether an xpath exists that refers to an attribute, to reduce the scope a bit.) Something like: "WARNING: CIB syntax changes may invalidate ACLs that use 'xpath'. It is strongly recommended to run 'cibadmin --upgrade' then go through the updated CIB carefully to ensure ACLs still match the desired intent."

In T898#14801, @kgaillot wrote:

Do you know what version of libxslt added support for dyn:evaluate? We only require 2.9.2 currently. I wouldn't mind using it to reduce the scope of the log further, but it's not necessary.

Since the risk of corner cases is so high, and our time for 3.0.0 is limited, I think the best approach would be to log a warning if a CIB contains ACLs with xpaths and the upgrade adds or renames any element or attribute. (We could possibly check whether an xpath exists that refers to an attribute, to reduce the scope a bit.) Something like: "WARNING: CIB syntax changes may invalidate ACLs that use 'xpath'. It is strongly recommended to run 'cibadmin --upgrade' then go through the updated CIB carefully to ensure ACLs still match the desired intent."

@kgaillot Can you weigh in when you have a chance? I know things are especially busy.
I figure it's unwise to work on the xpath case until we agree upon how we ought to address it -- if at all.

CLPR#3747 fixes the case of ACLs that refer to dropped elements, but it doesn't do anything special for replaced elements yet.

Fixed by rPc1f3ae1d9f (accidentally put wrong task number in commit message)

Following up on the state of this issue so I don't forget...

T904 is now planned instead of this

In T882#14340, @waltdisgrace wrote:

The output of crm_verify with /usr/share/pacemaker/upgrade-1.3-0.xsl moved to /tmp appears to contain suitable error messages. So did that part of this bug get fixed?

[root@pcmk-1 ~]# crm_verify -x $CIB_file
Relax-NG validity error : Extra element acls in interleave
Entity: line 16: element acls: Relax-NG validity error : Element configuration failed to validate content
Cannot upgrade configuration (claiming pacemaker-1.3 schema) to at least pacemaker-3.0 because it would not upgrade past pacemaker-1.3
The cluster will NOT be able to use this configuration.
Please manually update the configuration to conform to the pacemaker-3.10 syntax.
Errors found during check: config not valid
-V may provide more details

The output of crm_verify with /usr/share/pacemaker/upgrade-1.3-0.xsl moved to /tmp appears to contain suitable error messages. So did that part of this bug get fixed?

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.

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.