> I've been browsing through the cluster.log, and it's not even trying
> to move httpd. I'm almost certain that it used to work fine with
> resource sets. Hmm.
OK. I went and -actually looked- at the CIB I was previously generating.
This works:
>> I'm having difficulties figuring out what the 'right' way to do this is with
>> pcs
>
> You tried:
>
>pcs constraint colocation add asterisk with httpd
Yep. It ends up with asterisk stopped, and httpd happily running on -a
(and it won't start, because the colocation docs say 'if z is not
r
On 18 Nov 2013, at 12:43 pm, Rob Thomas wrote:
> Previously, using crm, it was reasonably painless to ensure that
> resource groups ran on the same node.
>
> I'm having difficulties figuring out what the 'right' way to do this is with
> pcs
You tried:
pcs constraint colocation add asteris
Previously, using crm, it was reasonably painless to ensure that
resource groups ran on the same node.
I'm having difficulties figuring out what the 'right' way to do this is with pcs
Specifically, I want the 'asterisk' group to run on the same node as
the 'httpd' group.
Basically, this should n
On 15 Nov 2013, at 2:28 pm, Sean Lutner wrote:
Yes the varnish resources are in a group which is then cloned.
>>>
>>> -EDONTDOTHAT
>>>
>>> You cant refer to the things inside a clone.
>>> 1.1.8 will have just been ignoring those constraints.
>>
>> So the implicit order and colocation con
>> Ahha. Look what I just spotted.
>>
>> https://github.com/feist/pcs/commit/8b888080c37ddea88b92dfd95aadd78b9db68b55
>
> Are you building pcs yourself or using the packages supplied by CentOS?
> I'd be surprised if the supplied packages had not been patched to look in
> cluster.conf instead of co
On 16 Nov 2013, at 9:42 am, Rob Thomas wrote:
>> Line 363 of /usr/lib/python2.6/site-packages/pcs/cluster.py has this:
>>
>>nodes = utils.getNodesFromCorosyncConf()
>
> Ahha. Look what I just spotted.
>
> https://github.com/feist/pcs/commit/8b888080c37ddea88b92dfd95aadd78b9db68b55
Are yo
