On 07/04/2016 07:13 AM, Ferenc Wágner wrote: > Ken Gaillot <kgail...@redhat.com> writes: > >> Does anyone know of an RA that uses reload correctly? > > My resource agents advertise a no-op reload action for handling their > "private" meta attributes. Meta in the sense that they are used by the > resource agent when performing certain operations, not by the managed > resource itself. Which means they are trivially changeable online, > without any resource operation whatsoever. > >> Does anyone object to the (backward-incompatible) solution proposed >> here? > > I'm all for cleanups, but please keep an online migration path around.
Not sure what you mean by online ... the behavior would change when Pacemaker was upgraded, so the node would already be out of the cluster at that point. You would unmanage resources if desired, stop pacemaker on the node, upgrade pacemaker, upgrade the RA, then start/manage again. If you mean that you would like to use the same RA before and after the upgrade, that would be doable. We could bump the crm feature set, which gets passed to the RA as an environment variable. You could modify the RA to handle both reload and reload-params, and if it's asked to reload, check the feature set to decide which type of reload to do. You could upgrade the RA anytime before the pacemaker upgrade. In pseudo-code, the recommended way of supporting reload would become: reload_params() { ... } reload_service() { ... } if action is "reload-params" then reload_params() else if action is "reload" if crm_feature_set < X.Y.Z then reload_params() else reload_service() Handling both "unique" and "reloadable" would be more complicated, but that's inherent in the mismash of meaning unique has right now. I see three approaches: 1. Use "unique" in its GUI sense and "reloadable" to indicate reloadable parameters. This would be cleanest, but would not be useful with pre-"reloadable" pacemaker. 2. Use both unique=0 and reloadable=1 to indicate reloadable parameters. This sacrifices proper GUI hinting to keep compatibility with pre- and post-"reloadable" pacemaker (the same sacrifice that has to be made now to use reload correctly). 3. Dynamically modify the metadata according to the crm feature set, using approach 1 with post-"reloadable" pacemaker and approach 2 with pre-"reloadable" pacemaker. This is the most flexible but makes the code more complicated. In pseudocode, it might look something like: if crm_feature_set < X.Y.Z then UNIQUE_TRUE="" UNIQUE_FALSE="" RELOADABLE_TRUE="unique=0" RELOADABLE_FALSE="unique=1" else UNIQUE_TRUE="unique=1" UNIQUE_FALSE="unique=0" RELOADABLE_TRUE="reloadable=1" RELOADABLE_FALSE="reloadable=0" meta_data() { ... <parameter name="my_param_1" $UNIQUE_TRUE $RELOADABLE_FALSE> ... <parameter name="my_param_2" $UNIQUE_FALSE $RELOADABLE_FALSE> } _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org