Hi, thanks for reply > On 21 Jun 2018, at 15:09, Jan Pokorný <[email protected]> wrote: > > Hello Salvatore, > > On 21/06/18 12:44 +0200, Salvatore D'angelo wrote: >> I am trying to upgrade my PostgresSQL cluster managed by pacemaker >> to pacemaker 1.1.8 or 2.0.0. I have some resource agents that I >> patched to have them working with my cluster. >> >> Can someone tell me if something is changed in the OCF interface >> from 1.1.14 release and the 1.1.8/2.0.0? > > You can consider the OCF specification/interface stable and no > breakages are really imminent.
Good to know > There are admittedly some parts with > less than well-defined semantics (if it's defined at all; for instance, > questions on what's the proper interpretation of "unique" slash > reloadable parameters was raised in the past [1,2]). > > This stability is moreover enforced with the requirement of cross > compatibility between various OCF conformant agent vs. resource > manager implementations (say those maintained in resource-agents > project vs. pacemaker, plus various versions thereof, without any > apriori defined ways of how to negotiate any further inteface > specifics, but see [3], for instance). > >> I am using the following resource agents: >> >> /usr/lib/ocf/resource.d/heartbeat/Filesystem >> /usr/lib/ocf/resource.d/heartbeat/ethmonitor >> /usr/lib/ocf/resource.d/heartbeat/pgsql (patched) > > ^ this is really contained within resource-agents project, and as > mentioned, nothing pushes you to update this piece of software > even if you intend to update pacemaker (granted, keeping step > with overall evolutionary "time snapshots" is always wise) > >> /usr/lib/ocf/resource.d/pacemaker/HealthCPU (patched) >> /usr/lib/ocf/resource.d/pacemaker/ping (patched) >> /usr/lib/ocf/resource.d/pacemaker/SysInfo (patched) > > ^ and these are from pacemaker's realms, so there's naturally > a closer coupling possibly beyond what standard mandates, but > again, OCF forms a "fixed point", basis upon which the graph > connecting the functionality user(s) and providers is formed, > so presumably you can mix and match various versions even if > the bits come from the very same project > >> I am doing some tests to verify this but I would like to know if >> there is at high level something I should be aware. > > Nothing comes to my mind, though your are always best served with > your own investigation (since you are modifying the agents anyway). > > As a rule of thumb, I'd start with checking the changelogs of the > mentioned projects, and deeper concerns can ultimately be resolved > with the review of cross-version changes on the source code level, > e.g.: > > git clone https://github.com/ClusterLabs/resource-agents.git > pushd resource-agents > # let's say you start with agents from v3.9.7 release > git diff v3.9.7 v4.1.1 -- heartbeat/{Filesystem,ethmonitor,pgsql} > popd > > git clone https://github.com/ClusterLabs/pacemaker.git > pushd pacemaker > git diff Pacemaker-1.1.14 Pacemaker-1.1.18 -- \ > extra/resources/{HealthCPU,SysInfo,ping} > popd > > It's more like showing how to fish than serving you a meal, > but hopefully this helps regardless (perhaps even more than > latter would do). > Yes, that’s exactly what I did. I just double checked. > > [1] https://lists.clusterlabs.org/pipermail/users/2016-June/010635.html > [2] https://lists.clusterlabs.org/pipermail/users/2017-September/013743.html > [3] https://github.com/ClusterLabs/OCF-spec/issues/17 > > -- > Jan (Poki) > _______________________________________________ > Users mailing list: [email protected] > https://lists.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 _______________________________________________ Users mailing list: [email protected] https://lists.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
