On 01/16/2019 04:34 PM, Ken Gaillot wrote: > On Wed, 2019-01-16 at 13:41 +0100, Valentin Vidic wrote: >> On Wed, Jan 16, 2019 at 12:41:11PM +0100, Valentin Vidic wrote: >>> This is what pacemaker says about the resource restarts: >>> >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Start dlm:1 ( node2 ) >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Start lockd:1 ( node2 ) >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Restart gfs2-lvm:0 ( node1 ) due to required >>> storage-clone running >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Restart gfs2-fs:0 ( node1 ) due to required >>> gfs2-lvm:0 start >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Start gfs2-lvm:1 ( node2 ) >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Start gfs2-fs:1 ( node2 ) >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Restart ocfs2-lvm:0 ( node1 ) due to required >>> storage-clone running >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Restart ocfs2-fs:0 ( node1 ) due to required >>> ocfs2-lvm:0 start >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Start ocfs2-lvm:1 ( node2 ) >>> Jan 16 11:19:08 node1 pacemaker-schedulerd[713]: notice: * >>> Start ocfs2-fs:1 ( node2 ) >> It seems interleave was required an gfs2 and ocfs2 clones: >> >> interleave (default: false) >> If this clone depends on another clone via an ordering constraint, >> is >> it allowed to start after the local instance of the other clone >> starts, rather >> than wait for all instances of the other clone to start? > Exactly, that's the purpose of interleave. > > In retrospect, interleave=true should have been the default. I've never > seen a case where false made sense, and people get bit by overlooking > it all the time. False is the default because it's (theoretically at > least) safer when there's nothing known about the particular service's > requirements. > > I should've flipped the default at 2.0.0 but didn't think of it. Now > we'll have to wait a decade for 3.0.0 :) or maybe we can justify doing > it in a minor bump in a few years. We don't have anything like clone-defaults - right? Maybe I'm missing where default-behavior of clones is covered already. If not that would at least be compatible and one would just have to think of that once.
Klaus > >> Now it behaves as expected when the node2 is set online: >> >> Jan 16 12:35:33 node1 pacemaker-schedulerd[564]: notice: * >> Start dlm:1 ( node2 ) >> Jan 16 12:35:33 node1 pacemaker-schedulerd[564]: notice: * >> Start lockd:1 ( node2 ) >> Jan 16 12:35:33 node1 pacemaker-schedulerd[564]: notice: * >> Start gfs2-lvm:1 ( node2 ) >> Jan 16 12:35:33 node1 pacemaker-schedulerd[564]: notice: * >> Start gfs2-fs:1 ( node2 ) >> Jan 16 12:35:33 node1 pacemaker-schedulerd[564]: notice: * >> Start ocfs2-lvm:1 ( node2 ) >> Jan 16 12:35:33 node1 pacemaker-schedulerd[564]: notice: * >> Start ocfs2-fs:1 ( node2 ) >> >> Clone: gfs2-clone >> Meta Attrs: interleave=true target-role=Started >> Group: gfs2 >> Resource: gfs2-lvm (class=ocf provider=heartbeat type=LVM- >> activate) >> Attributes: activation_mode=shared vg_access_mode=lvmlockd >> vgname=vgshared lvname=gfs2 >> Resource: gfs2-fs (class=ocf provider=heartbeat type=Filesystem) >> Attributes: directory=/srv/gfs2 fstype=gfs2 >> device=/dev/vgshared/gfs2 >> > _______________________________________________ > 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
