Support OCF 1.1 reload-agent action #2349
Conversation
|
@wenningerk , can you review this when you get a chance? Thanks |
|
lgtm |
With the release of the OCF 1.1 standard, this information may come in handy during troubleshooting. We warn if the RA does not advertise an OCF version, or if it advertises a major version higher than what Pacemaker supports, and otherwise log a debug message with the supported version.
... for new OCF 1.1 "reload-agent" action
... and formatting
This will make it easier to add new criteria.
... for better code isolation and future reuse
Pacemaker previously used the "reload" action to reload agent parameters, but most agents used it to reload the service configuration. Pacemaker also misused the OCF 1.0 "unique" parameter attribute to indicate reloadability. OCF 1.1 created the "reload-agent" action and "reloadable" parameter attribute for the Pacemaker usage. Pacemaker now supports the OCF 1.1 usage. The old usage is now deprecated, but will be supported if the agent does not claim OCF 1.1 or later compliance and does not advertise the reload-agent action.
... unless Pacemaker was built using --enable-compat-2.0, in which case it's really 1.0 with extensions.
In a rolling upgrade, the DC can't schedule reload-agent actions until all nodes have been upgraded.
... to make future changes less error-prone
|
Rebased on current master and added 5 commits on top to address review |
|
After further testing, I added 2 more commits on top -- one to fix a regression since 1.1.18 (!) and one to always advertise OCF 1.1 support to agents (since we do support 1.1 agents regardless of compatibility settings). @wenningerk , can you review the top 7 commits? Thanks ... |
The top 4 - looked at just that far are fine for me. |
c820651 (in 1.1.18) introduced a regression where cached meta-data was allowed to be used after a start action. Meta-data should always be refreshed from the agent after a start, in case the resource agent was updated.
Upon further consideration, Pacemaker should advertise OCF 1.1 support to agents even when built with --enable-compat-2.0, because Pacemaker supports the OCF 1.1 role names and reload-agent action in the agent either way, even if it's not using the new role names in log messages and output itself.
... to make its purpose clearer
|
OK, I still have a little testing to do, but hopefully this is the final form. The last 4 commits are different from last time. |
changes looking good to me |
Pacemaker previously used the "reload" action to reload agent parameters, but most agents used it to reload the service configuration. Pacemaker also misused the OCF 1.0 "unique" parameter attribute to indicate reloadability.
OCF 1.1 created the "reload-agent" action and "reloadable" parameter attribute for the Pacemaker usage.
Pacemaker now supports the OCF 1.1 usage. The old usage is now deprecated, but will be supported if the agent does not claim OCF 1.1 or later compliance and does not advertise the reload-agent action.
Special care must be taken so that rolling upgrades work (i.e. an older DC will still schedule reload commands), and that the controller chooses reload or reload-agent based on what the resource meta-data advertises, regardless of what command the DC schedules. (Technically that means we didn't have to change what the DC schedules, but I think having it schedule reload-agent will be less confusing.)