crm_resource already uses G_OPTION_REMAINING to collect the remaining arguments into an array. Then after parsing all options, it logs those remaining arguments if they're invalid. However, they're valid if we're running a subcommand that uses options.override_params.

There's a LOT that I still don't understand about the scheduler (especially with regard to colocation), but I've probably reviewed or modified more of that code than anyone who's still on the team.

For posterity, re: "reverting change" -- the XML ID is now part of the priv struct, so from the public API's perspective that commit has not been reverted.

@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#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.

@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.