<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#444444">Thanks a bunch for the advice, but finally is easier than I thought, I will simply use a different configuration for each apache server, but still maintaning replication via DRBD (DB/FS).</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#444444"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#444444">Again, thanks for the reply @Dimitri.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#444444"> </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#444444">Hugs from Chile!!</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:#444444"> </div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><b style="color:rgb(7,55,99);font-family:verdana,sans-serif;font-size:small"><br></b></div><div dir="ltr"><b style="color:rgb(7,55,99);font-family:verdana,sans-serif;font-size:small">---</b></div><div dir="ltr"><b style="color:rgb(7,55,99);font-family:verdana,sans-serif;font-size:small">Ronny Machado C.</b><br></div><div dir="ltr"><div style="font-size:small"><div style="font-family:verdana,sans-serif"><font color="#073763"><b>  ​IT Consultant​</b></font></div></div><div style="font-size:small"><font face="verdana, sans-serif" color="#073763"><b> +569 75199262</b></font></div><div style="font-size:small"><font face="verdana, sans-serif" color="#073763"><div style="display:inline"><a href="http://www.aaconsultoria.cl/" style="color:rgb(17,85,204)" target="_blank"><b>​</b></a></div></font></div></div><div dir="ltr"><br><div><b><font color="#666666"><br>
</font></b></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On 1 December 2016 at 08:00,  <span dir="ltr"><<a href="mailto:users-request@clusterlabs.org" target="_blank">users-request@clusterlabs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Users mailing list submissions to<br>
        <a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:users-request@clusterlabs.org">users-request@clusterlabs.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:users-owner@clusterlabs.org">users-owner@clusterlabs.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: ocf:heartbeat:IPaddr2 - Different network segment<br>
      (Dimitri Maziuk)<br>
   2. Re: ocf:heartbeat:IPaddr2 - Different network segment<br>
      (Dimitri Maziuk)<br>
   3. Pacemaker 1.1.16 released (Ken Gaillot)<br>
   4. Re: Antw: Re: Set a node attribute for multiple nodes with<br>
      one command (Ken Gaillot)<br>
   5. Deleting a variable (Ulrich Windl)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 30 Nov 2016 12:19:03 -0600<br>
From: Dimitri Maziuk <<a href="mailto:dmaziuk@bmrb.wisc.edu">dmaziuk@bmrb.wisc.edu</a>><br>
To: <a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a><br>
Subject: Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network<br>
        segment<br>
Message-ID: <<a href="mailto:057788d3-be24-05c9-c8bd-190237057b6b@bmrb.wisc.edu">057788d3-be24-05c9-c8bd-<wbr>190237057b6b@bmrb.wisc.edu</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 11/30/2016 09:10 AM, Ronny Machado C. wrote:<br>
...any advice on how to<br>
> use  ocf:heartbeat:IPaddr2 ip=x.x.x.x but in different segments, maybe is<br>
> super easy, but  right now I can't find out how.<br>
<br>
ICBW but if you bring up an ip in the wrong segment, it'll just be<br>
unroutable/unreachable. As long as outgoing packets don't have it as<br>
their from address, you should be fine.<br>
<br>
I.e. just have both ips up on either node and see what happens.<br>
<br>
--<br>
Dimitri Maziuk<br>
Programmer/sysadmin<br>
BioMagResBank, UW-Madison -- <a href="http://www.bmrb.wisc.edu" rel="noreferrer" target="_blank">http://www.bmrb.wisc.edu</a><br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 190 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://clusterlabs.org/pipermail/users/attachments/20161130/2ad706d5/attachment-0001.sig" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>pipermail/users/attachments/<wbr>20161130/2ad706d5/attachment-<wbr>0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 30 Nov 2016 12:24:05 -0600<br>
From: Dimitri Maziuk <<a href="mailto:dmaziuk@bmrb.wisc.edu">dmaziuk@bmrb.wisc.edu</a>><br>
To: <a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a><br>
Subject: Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network<br>
        segment<br>
Message-ID: <<a href="mailto:d000f619-a395-1379-0259-5e0f05dfd337@bmrb.wisc.edu">d000f619-a395-1379-0259-<wbr>5e0f05dfd337@bmrb.wisc.edu</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
PS you could probably use iptables to block/log outgoing traffic from<br>
the wrong ip (different on each node) to be really really sure.<br>
<br>
--<br>
Dimitri Maziuk<br>
Programmer/sysadmin<br>
BioMagResBank, UW-Madison -- <a href="http://www.bmrb.wisc.edu" rel="noreferrer" target="_blank">http://www.bmrb.wisc.edu</a><br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 190 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://clusterlabs.org/pipermail/users/attachments/20161130/2a0fc3be/attachment-0001.sig" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>pipermail/users/attachments/<wbr>20161130/2a0fc3be/attachment-<wbr>0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 30 Nov 2016 14:05:19 -0600<br>
From: Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
To: Cluster Labs - All topics related to open-source clustering<br>
        welcomed        <<a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a>><br>
Subject: [ClusterLabs] Pacemaker 1.1.16 released<br>
Message-ID: <<a href="mailto:b2510d57-79f4-927f-8315-67d81f03995e@redhat.com">b2510d57-79f4-927f-8315-<wbr>67d81f03995e@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
ClusterLabs is proud to announce the latest release of the Pacemaker<br>
cluster resource manager, version 1.1.15. The source code is available at:<br>
<br>
<a href="https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1.16" rel="noreferrer" target="_blank">https://github.com/<wbr>ClusterLabs/pacemaker/<wbr>releases/tag/Pacemaker-1.1.16</a><br>
The most significant enhancements in this release are:<br>
<br>
* rsc-pattern may now be used instead of rsc in location constraints, to<br>
allow a single location constraint to apply to all resources whose names<br>
match a regular expression. Sed-like %0 - %9 backreferences let<br>
submatches be used in node attribute names in rules.<br>
<br>
* The new ocf:pacemaker:attribute resource agent sets a node attribute<br>
according to whether the resource is running or stopped. This may be<br>
useful in combination with attribute-based rules to model dependencies<br>
that simple constraints can't handle.<br>
<br>
* Pacemaker's existing "node health" feature allows resources to move<br>
off nodes that become unhealthy. Now, when using<br>
node-health-strategy=<wbr>progressive, a new cluster property<br>
node-health-base will be used as the initial health score of newly<br>
joined nodes (defaulting to 0, which is the previous behavior). This<br>
allows a node to be treated as "healthy" even if it has some "yellow"<br>
health attributes, which can be useful to allow clones to run on such nodes.<br>
<br>
* Previously, the OCF_RESKEY_CRM_meta_notify_<wbr>active_* variables were not<br>
properly passed to multistate resources with notification enabled. This<br>
has been fixed. To help resource agents detect when the fix is<br>
available, the CRM feature set has been incremented. (Whenever the<br>
feature set changes, mixed-version clusters are supported only during<br>
rolling upgrades -- nodes with an older version will not be allowed to<br>
rejoin once they shut down.)<br>
<br>
* Watchdog-based fencing using sbd now works better on remote nodes.<br>
This capability still likely has some limitations, however.<br>
<br>
* The build process now takes advantage of various compiler features<br>
(RELRO, PIE, as-needed linking, etc.) that enhance security and start-up<br>
performance. See the "Hardening flags" comments in the <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> file<br>
for more details.<br>
<br>
* Python 3 compatibility: The Pacemaker project now targets<br>
compatibility with both python 2 (versions 2.6 and later) and python 3<br>
(versions 3.2 and later). All of the project's python code now meets<br>
this target, with the exception of CTS, which is still python 2 only.<br>
<br>
* The Pacemaker coding guidelines have been replaced by a more<br>
comprehensive addition to the documentation set, "Pacemaker<br>
Development". It is intended for developers working on the Pacemaker<br>
code base itself, rather than external code such as resource agents. A<br>
copy is viewable at<br>
<a href="http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Development/" rel="noreferrer" target="_blank">http://clusterlabs.org/doc/en-<wbr>US/Pacemaker/1.1-pcs/html-<wbr>single/Pacemaker_Development/</a><br>
<br>
As usual, the release includes many bugfixes, including a fix for a<br>
serious security vulnerability (CVE-2016-7035). For a more detailed list<br>
of changes, see the change log:<br>
<br>
<a href="https://github.com/ClusterLabs/pacemaker/blob/1.1/ChangeLog" rel="noreferrer" target="_blank">https://github.com/<wbr>ClusterLabs/pacemaker/blob/1.<wbr>1/ChangeLog</a><br>
<br>
Many thanks to all contributors of source code to this release,<br>
including Andrew Beekhof, Bin Liu, Christian Schneider, Christoph Berg,<br>
David Shane Holden, Ferenc W?gner, Yan Gao, Hideo Yamauchi, Jan Pokorn?,<br>
Ken Gaillot, Klaus Wenninger, Kostiantyn Ponomarenko, Kristoffer<br>
Gr?nlund, Lars Ellenberg, Masatake Yamato, Michal Koutn?, Nakahira<br>
Kazutomo, Nate Clark, Nishanth Aravamudan, Oyvind Albrigtsen, Ruben<br>
Kerkhof, Tim Bishop, Vladislav Bogdanov and Yusuke Iida. Apologies if I<br>
have overlooked anyone.<br>
--<br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 30 Nov 2016 14:39:27 -0600<br>
From: Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
To: Kostiantyn Ponomarenko <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.<wbr>com</a>><br>
Cc: Cluster Labs - All topics related to open-source clustering<br>
        welcomed        <<a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a>><br>
Subject: Re: [ClusterLabs] Antw: Re: Set a node attribute for multiple<br>
        nodes with one command<br>
Message-ID: <<a href="mailto:62cb811f-4396-ff36-ec03-67000b4ed07b@redhat.com">62cb811f-4396-ff36-ec03-<wbr>67000b4ed07b@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 11/30/2016 11:31 AM, Kostiantyn Ponomarenko wrote:<br>
> Hi Ken,<br>
><br>
> I didn't look into the logs, but I experimented with it for a while.<br>
> Here is what I found.<br>
><br>
> It worked for you because this attribute - "my-attr" - has not ever been<br>
> set before in that cluster.<br>
><br>
> So if you set an attribute, then remove it, and then set it with<br>
> "--delay", like:<br>
><br>
>     # attrd_updater -N node-0 -n my-attr --update false --delay 20<br>
><br>
> , this delay (dampening) won't work.<br>
<br>
Once set, attributes are not truly deleted -- only their values are<br>
cleared. And --delay has no effect with --update if the attribute<br>
already exists, which is what you see above.<br>
<br>
To set a delay on an already existing attribute, you have to use<br>
attrd_updater --update-delay or --update-both.<br>
<br>
> Moreover, when you delete this attribute the actual remove will be<br>
> delayed by that "--delay" which was used when the attribute was set.<br>
><br>
><br>
> Thank you,<br>
> Kostia<br>
><br>
> On Tue, Nov 29, 2016 at 1:08 AM, Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a><br>
> <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>>> wrote:<br>
><br>
>     On 11/24/2016 05:24 AM, Kostiantyn Ponomarenko wrote:<br>
>     > Attribute dampening doesn't work for me also.<br>
>     > To test that I have a script:<br>
>     ><br>
>     >     attrd_updater -N node-0 -n my-attr --update false --delay 20<br>
>     >     sleep 3<br>
>     >     attrd_updater -N node-0 -n my-attr --update true<br>
>     >     sleep 7<br>
>     >     attrd_updater -N node-1 -n my-attr --update true<br>
><br>
>     This sequence works for me -- the attributes are not written to the live<br>
>     CIB until the end of the delay, when both are written at the same time.<br>
><br>
>     The remaining issue must be with the policy engine. You could look at<br>
>     the detail log on the DC when these changes were made; you should see<br>
>     info-level messages with the CIB change with both values together (lines<br>
>     with "cib_perform_op:   ++" and the attribute values), then "Transition<br>
>     aborted" with "Transient attribute change", then a bunch of "pengine:"<br>
>     lines saying what the cluster wants to do with each resource.<br>
><br>
>     There should be some information about the scores used to place the<br>
>     resources.<br>
><br>
>     ><br>
>     > All my resources have this rule in Pacemaker config:<br>
>     ><br>
>     >     crm configure location res1-location-rule res1 \<br>
>     >         rule 0: my-attr eq true \<br>
>     >         rule -inf: my-attr ne true<br>
>     ><br>
>     > On a working two-node cluster I remove "my-attr" from both nodes.<br>
>     > Then run my script. And all resources start on node-0.<br>
>     > Am I doing something wrong?<br>
>     > Or maybe my understanding of an attribute dampening is not correct?<br>
>     ><br>
>     > My Pacemaker version is 1.1.13. (heh, not the last one, but it is what<br>
>     > it is ...)<br>
>     ><br>
>     > Thank you,<br>
>     > Kostia<br>
>     ><br>
>     > On Wed, Nov 23, 2016 at 7:27 PM, Kostiantyn Ponomarenko<br>
>     > <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.<wbr>com</a><br>
>     <mailto:<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.<wbr>ponomarenko@gmail.com</a>><br>
>     > <mailto:<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.<wbr>ponomarenko@gmail.com</a><br>
>     <mailto:<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.<wbr>ponomarenko@gmail.com</a>>>> wrote:<br>
>     ><br>
>     >     Maybe I am doing something wrong, but I cannot set "status" section<br>
>     >     node attributes to a shadow cib, cluster applies them immediately.<br>
>     >     To try it out I do in a console:<br>
>     ><br>
>     >         crm_shadow --create test<br>
>     >         crm_attribute --type nodes --node node-0 --name my-attribute<br>
>     >     --update 1 --lifetime=reboot<br>
>     ><br>
>     >     And this attribute is set to the live cluster configuration immediately.<br>
>     >     What am I doing wrong?<br>
>     ><br>
>     >     Thank you,<br>
>     >     Kostia<br>
>     ><br>
>     >     On Tue, Nov 22, 2016 at 11:33 PM, Kostiantyn Ponomarenko<br>
>     >     <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.<wbr>com</a><br>
>     <mailto:<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.<wbr>ponomarenko@gmail.com</a>><br>
>     >     <mailto:<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.<wbr>ponomarenko@gmail.com</a><br>
>     <mailto:<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.<wbr>ponomarenko@gmail.com</a>>>> wrote:<br>
>     ><br>
>     >         Ken,<br>
>     >         Thank you for the explanation.<br>
>     >         I will try this low-level way of shadow cib creation tomorrow.<br>
>     >         PS: I will sleep much better with this excellent news/idea. =)<br>
>     ><br>
>     >         Thank you,<br>
>     >         Kostia<br>
>     ><br>
>     >         On Tue, Nov 22, 2016 at 10:53 PM, Ken Gaillot<br>
>     >         <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a> <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
>     <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a> <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>>>> wrote:<br>
>     ><br>
>     >             On 11/22/2016 04:39 AM, Kostiantyn Ponomarenko wrote:<br>
>     >             > Using "shadow cib" in crmsh looks like a good idea, but it doesn't work<br>
>     >             > with node attributes set into "status" section of Pacemaker config.<br>
>     >             > I wonder it it is possible to make it work that way.<br>
>     ><br>
>     >             Forgot to mention -- the shadow CIB is probably the best way<br>
>     >             to do this.<br>
>     >             I don't know if there's a way to do it in crmsh, but you can<br>
>     >             use it with<br>
>     >             the low-level commands crm_shadow and crm_attribute<br>
>     >             --lifetime=reboot.<br>
>     ><br>
>     >             > Ken,<br>
>     >             >>> start dampening timer<br>
>     >             > Could you please elaborate more on this. I don't get how I can set this<br>
>     >             > timer.<br>
>     >             > Do I need to set this timer for each node?<br>
>     >             ><br>
>     >             ><br>
>     >             > Thank you,<br>
>     >             > Kostia<br>
>     >             ><br>
>     >             > On Mon, Nov 21, 2016 at 9:30 AM, Ulrich Windl<br>
>     >             > <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a><br>
>     <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a>><br>
>     >             <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a><br>
>     <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a>>><br>
>     >             > <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a><br>
>     <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a>><br>
>     >             <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a><br>
>     <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a>>>>> wrote:<br>
>     >             ><br>
>     >             >     >>> Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a> <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
>     >             <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a><br>
>     <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>>> <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a><br>
>     <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
>     >             <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a> <mailto:<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>>>><wbr>><br>
>     >             >     schrieb am 18.11.2016 um 16:17 in Nachricht<br>
>     >             >     <<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-00be-<wbr>e772d8e382ca@redhat.com</a><br>
>     <mailto:<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-<wbr>00be-e772d8e382ca@redhat.com</a>><br>
>     >             <mailto:<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-<wbr>00be-e772d8e382ca@redhat.com</a><br>
>     <mailto:<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-<wbr>00be-e772d8e382ca@redhat.com</a>>><br>
>     >             ><br>
>     ><br>
>     <mailto:<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-<wbr>00be-e772d8e382ca@redhat.com</a><br>
>     <mailto:<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-<wbr>00be-e772d8e382ca@redhat.com</a>><br>
>     ><br>
>      <mailto:<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-<wbr>00be-e772d8e382ca@redhat.com</a><br>
>     <mailto:<a href="mailto:d6f449da-64f8-12ad-00be-e772d8e382ca@redhat.com">d6f449da-64f8-12ad-<wbr>00be-e772d8e382ca@redhat.com</a>>><wbr>>>:<br>
>     >             >     > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko<br>
>     wrote:<br>
>     >             >     >> Hi folks,<br>
>     >             >     >><br>
>     >             >     >> Is there a way to set a node attribute to the<br>
>     >             "status" section for few<br>
>     >             >     >> nodes at the same time?<br>
>     >             >     >><br>
>     >             >     >> In my case there is a node attribute which allows<br>
>     >             some resources to<br>
>     >             >     >> start in the cluster if it is set.<br>
>     >             >     >> If I set this node attribute for say two<br>
>     nodes in a<br>
>     >             way - one and then<br>
>     >             >     >> another, than these resources are not distributed<br>
>     >             equally between these<br>
>     >             >     >> two nodes. That because Pacemaker picks the first<br>
>     >             node to with this<br>
>     >             >     >> attribute is set and immediately starts all<br>
>     allowed<br>
>     >             resources on it. And<br>
>     >             >     >> this is not the behavior i would like to get.<br>
>     >             >     >><br>
>     >             >     >> Thank you,<br>
>     >             >     >> Kostia<br>
>     >             >     ><br>
>     >             >     > Not that I know of, but it would be a good feature<br>
>     >             to add to<br>
>     >             >     > attrd_updater and/or crm_attribute.<br>
>     >             ><br>
>     >             >     With crm (shell) you don't have transactions for<br>
>     node<br>
>     >             attributes,<br>
>     >             >     but for the configuration. So if you add a location<br>
>     >             restriction<br>
>     >             >     preventing any resources on your nodes, then enable<br>
>     >             the nodes, and<br>
>     >             >     then delete the location restrictions in one<br>
>     >             transaction, you might<br>
>     >             >     get what you want. It's not elegant, but itt ill do.<br>
>     >             ><br>
>     >             >     To the crm shell maintainer: Is is difficult to<br>
>     build<br>
>     >             transactions<br>
>     >             >     to node status changes? The problem I see is<br>
>     this: For<br>
>     >             configuration<br>
>     >             >     you always have transactions (requiring<br>
>     "commit), but<br>
>     >             for nodes you<br>
>     >             >     traditionally have non (effects are immediate). So<br>
>     >             you'd need a<br>
>     >             >     thing like "start transaction" which requires a<br>
>     >             "commit" or some<br>
>     >             >     kind of abort later.<br>
>     >             ><br>
>     >             >     I also don't know whether a "shadow CIB" would help<br>
>     >             for the original<br>
>     >             >     problem.<br>
>     >             ><br>
>     >             >     Ulrich<br>
>     >             ><br>
>     >             >     ><br>
>     >             >     > You can probably hack it with a dampening<br>
>     value of a<br>
>     >             few seconds. If<br>
>     >             >     > your rule checks for a particular value of the<br>
>     >             attribute, set all the<br>
>     >             >     > nodes to a different value first, which will write<br>
>     >             that value and<br>
>     >             >     start<br>
>     >             >     > the dampening timer. Then set all the<br>
>     attributes to<br>
>     >             the desired value,<br>
>     >             >     > and they will get written out together when the<br>
>     >             timer expires.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 01 Dec 2016 08:15:52 +0100<br>
From: "Ulrich Windl" <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-<wbr>regensburg.de</a>><br>
To: <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>><br>
Cc: <a href="mailto:users@clusterlabs.org">users@clusterlabs.org</a><br>
Subject: [ClusterLabs] Deleting a variable<br>
Message-ID: <<a href="mailto:583FDC38020000A10002375E@gwsmtp1.uni-regensburg.de">583FDC38020000A10002375E@<wbr>gwsmtp1.uni-regensburg.de</a>><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
>>> Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> schrieb am 30.11.2016 um 21:39 in Nachricht<br>
<<a href="mailto:62cb811f-4396-ff36-ec03-67000b4ed07b@redhat.com">62cb811f-4396-ff36-ec03-<wbr>67000b4ed07b@redhat.com</a>>:<br>
<br>
[...]<br>
> Once set, attributes are not truly deleted -- only their values are<br>
> cleared. And --delay has no effect with --update if the attribute<br>
> already exists, which is what you see above.<br>
<br>
Is there a difference between a "deleted" variable and a defined variable that has an empty string as value? I feel there should be!<br>
<br>
[...]<br>
<br>
Ulrich<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
<br>
End of Users Digest, Vol 23, Issue 1<br>
******************************<wbr>******<br>
</blockquote></div><br></div>