On Thu, 2018-01-11 at 20:11 +0300, Andrei Borzenkov wrote: > 11.01.2018 19:21, Ken Gaillot пишет: > > On Thu, 2018-01-11 at 01:16 +0100, Jehan-Guillaume de Rorthais > > wrote: > > > On Wed, 10 Jan 2018 12:23:59 -0600 > > > Ken Gaillot <kgail...@redhat.com> wrote: > > > ... > > > > My question is: has anyone used or tested this, or is anyone > > > > interested > > > > in this? We won't promote it to the default schema unless it is > > > > tested. > > > > > > > > My feeling is that it is more likely to be confusing than > > > > helpful, > > > > and > > > > there are probably ways to achieve any reasonable use case with > > > > existing syntax. > > > > > > For what it worth, I tried to implement such solution to dispatch > > > mulitple > > > IP addresses to slaves in a 1 master 2 slaves cluster. This is > > > quite > > > time > > > consuming to wrap its head around sides effects with colocation, > > > scores and > > > stickiness. My various tests shows everything sounds to behave > > > correctly now, > > > but I don't feel really 100% confident about my setup. > > > > > > I agree that there are ways to achieve such a use case with > > > existing > > > syntax. > > > But this is quite confusing as well. As instance, I experienced a > > > master > > > relocation when messing with a slave to make sure its IP would > > > move > > > to the > > > other slave node...I don't remember exactly what was my error, > > > but I > > > could > > > easily dig for it if needed. > > > > > > I feel like it fits in the same area that the usability of > > > Pacemaker. > > > Making it > > > easier to understand. See the recent discussion around the > > > gocardless > > > war story. > > > > > > My tests was mostly for labs, demo and tutorial purpose. I don't > > > have > > > a > > > specific field use case. But if at some point this feature is > > > promoted > > > officially as preview, I'll give it some testing and report here > > > (barring the > > > fact I'm actually aware some feedback are requested ;)). > > > > It's ready to be tested now -- just do this: > > > > cibadmin --upgrade > > cibadmin --modify --xml-text '<cib validate-with="pacemaker- > > next"/>' > > > > Then use constraints like: > > > > <rsc_colocation id="id0" score="100" > > rsc="rsc1" > > with-rsc="clone1" with-rsc-instance="1" /> > > > > <rsc_colocation id="id1" score="100" > > rsc="rsc2" > > with-rsc="clone1" with-rsc-instance="2" /> > > > > to colocate rsc1 and rsc2 with separate instances of clone1. There > > is > > no way to know *which* instance of clone1 will be 1, 2, etc.; this > > just > > allows you to ensure the colocations are separate. > > > > Is it possible to designate master/slave as well?
If you mean constrain one resource to the master, and a bunch of other resources to the slaves, then no, this new syntax doesn't support that. But it should be possible with existing syntax, by constraining with role=master or role=slave, then anticolocating the resources with each other. > > > Similarly you can use rsc="clone1" rsc-instance="1" to colocate a > > clone > > instance relative to another resource instead. > > > > For ordering, the corresponding syntax is "first-instance" or > > "then- > > instance" as desired. > > > > I believe crm shell has higher-level support for this feature. > > > > Personally, I think standard colocations of rsc1 and rsc2 with > > clone1, > > and then an anticolocation between rsc1 and rsc2, would be more > > intuitive. You're right that the interactions with stickiness etc. > > can > > be tricky, but that would apply to the alternate syntax as well. > > > > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > http://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 -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org http://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
