[Pacemaker] Remove a "ghost" node

[Andrew Beekhof]

On 19 Nov 2013, at 3:21 am, Sean Lutner <sean at rentul.net> wrote:

> 
> On Nov 17, 2013, at 7:40 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
> 
>> 
>> On 15 Nov 2013, at 2:28 pm, Sean Lutner <sean at rentul.net> 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 constraints in a group and clone will take care of those?
>>>> 
>>>> Which means remove the constraints and retry the upgrade?
>> 
>> No, it means rewrite them to refer to the clone - whatever is the outer most container. 
> 
> I see, thanks. Did I miss that in the docs or is it undocumented/implied? If I didn't miss it, it'd be nice if that were explicitly documented.

Assuming:

<clone id=X ...>
  <primitive id=Y .../>
</clone>

For most of pacemaker's existence, it simply wasn't possible because there is no resource named Y (they were actually called Y:0 Y:1 .. Y:N).
Then pacemaker was made smarter and as a side effect, started being able to find something matching "Y".

Then I closed the loophole :)

So it was never legal.

> 
> Is there a combination of constraints I can configure for a single IP resource and a cloned group such that if there is a failure only the IP resource will move?

These are implied simply because they're in a group:

      <rsc_order first="Varnish" id="order-Varnish-Varnishlog-mandatory" then="Varnishlog"/>
      <rsc_order first="Varnishlog" id="order-Varnishlog-Varnishncsa-mandatory" then="Varnishncsa"/>
      <rsc_colocation id="colocation-Varnishlog-Varnish-INFINITY" rsc="Varnishlog" score="INFINITY" with-rsc="Varnish"/>
      <rsc_colocation id="colocation-Varnishncsa-Varnishlog-INFINITY" rsc="Varnishncsa" score="INFINITY" with-rsc="Varnishlog"/>
This:

      <rsc_order first="ClusterEIP_54.215.143.166" id="order-ClusterEIP_54.215.143.166-Varnish-mandatory" then="Varnish"/>

can be replaced with:

      pcs constraint order start ClusterEIP_54.215.143.166 then EIP-AND-VARNISH-clone

and:

      <rsc_colocation id="colocation-Varnish-ClusterEIP_54.215.143.166-INFINITY" rsc="Varnish" score="INFINITY" with-rsc="ClusterEIP_54.215.143.166"/>

is the same as:

      pcs constraint colocation EIP-AND-VARNISH-clone with ClusterEIP_54.215.143.166 

but that makes no sense because then the clone (which wants to run everywhere) can only run on the node the IP is on.
If thats what you want, then there is no point having a clone.

Better to reverse the colocation to be:

      pcs constraint colocation ClusterEIP_54.215.143.166 with EIP-AND-VARNISH-clone

and possibly the ordering too:

      pcs constraint order start EIP-AND-VARNISH-clone then ClusterEIP_54.215.143.166 


> Or in the case where I previously had the constraints applied to the resources and not the clone was that causing a problem?
> 
> Thanks again.
> 
> 
>> 
>>> 
>>> I was able to get the upgrade done. I also had to upgrade the libqb package. I know that's been mentioned in other threads, but I think that should either be a dependency of pacemaker or explicitly documented.
>> 
>> libqb is a dependancy, just not a versioned one.
>> We should probably change that next time.
> 
> I would say it's a requirement that that be changed.

Well... pacemaker can build against older versions, but you need to run it with whatever version you built against.
possibly the libqb versioning is being done incorrectly preventing rpm from figuring this all out

> 
>> 
>>> 
>>> Second order of business is that failover is no longer working as expected. Because the order and colocation constraints are gone, if one of the varnish resources fails, the EIP resource does not move to the other node like it used to.
>>> 
>>> Is there a way I can create or re-create that behavior?
>> 
>> See above :)
>> 
>>> 
>>> The resource group EIP-AND_VARNISH has the three varnish services and is then cloned so running on both nodes. If any of them fail I want the EIP resource to move to the other node.
>>> 
>>> Any advice for doing this?
>>> 
>>> Thanks
>> 
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> 
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20131119/bd87cafd/attachment-0003.sig>