[ClusterLabs] Deleting a variable

2016-11-30 Thread Ulrich Windl 
>>> Ken Gaillot  schrieb am 30.11.2016 um 21:39 in 
>>> Nachricht
<62cb811f-4396-ff36-ec03-67000b4ed...@redhat.com>:

[...]
> Once set, attributes are not truly deleted -- only their values are
> cleared. And --delay has no effect with --update if the attribute
> already exists, which is what you see above.

Is there a difference between a "deleted" variable and a defined variable that 
has an empty string as value? I feel there should be!

[...]

Ulrich



___
Users mailing list: Users@clusterlabs.org
http://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

Re: [ClusterLabs] Antw: Re: Set a node attribute for multiple nodes with one command

2016-11-30 Thread Ken Gaillot 
On 11/30/2016 11:31 AM, Kostiantyn Ponomarenko wrote:
> Hi Ken,
> 
> I didn't look into the logs, but I experimented with it for a while.
> Here is what I found.
> 
> It worked for you because this attribute - "my-attr" - has not ever been
> set before in that cluster.
> 
> So if you set an attribute, then remove it, and then set it with
> "--delay", like:
> 
> # attrd_updater -N node-0 -n my-attr --update false --delay 20
> 
> , this delay (dampening) won't work.

Once set, attributes are not truly deleted -- only their values are
cleared. And --delay has no effect with --update if the attribute
already exists, which is what you see above.

To set a delay on an already existing attribute, you have to use
attrd_updater --update-delay or --update-both.

> Moreover, when you delete this attribute the actual remove will be
> delayed by that "--delay" which was used when the attribute was set.
> 
> 
> Thank you,
> Kostia
> 
> On Tue, Nov 29, 2016 at 1:08 AM, Ken Gaillot  > wrote:
> 
> On 11/24/2016 05:24 AM, Kostiantyn Ponomarenko wrote:
> > Attribute dampening doesn't work for me also.
> > To test that I have a script:
> >
> > attrd_updater -N node-0 -n my-attr --update false --delay 20
> > sleep 3
> > attrd_updater -N node-0 -n my-attr --update true
> > sleep 7
> > attrd_updater -N node-1 -n my-attr --update true
> 
> This sequence works for me -- the attributes are not written to the live
> CIB until the end of the delay, when both are written at the same time.
> 
> The remaining issue must be with the policy engine. You could look at
> the detail log on the DC when these changes were made; you should see
> info-level messages with the CIB change with both values together (lines
> with "cib_perform_op:   ++" and the attribute values), then "Transition
> aborted" with "Transient attribute change", then a bunch of "pengine:"
> lines saying what the cluster wants to do with each resource.
> 
> There should be some information about the scores used to place the
> resources.
> 
> >
> > All my resources have this rule in Pacemaker config:
> >
> > crm configure location res1-location-rule res1 \
> > rule 0: my-attr eq true \
> > rule -inf: my-attr ne true
> >
> > On a working two-node cluster I remove "my-attr" from both nodes.
> > Then run my script. And all resources start on node-0.
> > Am I doing something wrong?
> > Or maybe my understanding of an attribute dampening is not correct?
> >
> > My Pacemaker version is 1.1.13. (heh, not the last one, but it is what
> > it is ...)
> >
> > Thank you,
> > Kostia
> >
> > On Wed, Nov 23, 2016 at 7:27 PM, Kostiantyn Ponomarenko
> >  
> >  >> wrote:
> >
> > Maybe I am doing something wrong, but I cannot set "status" section
> > node attributes to a shadow cib, cluster applies them immediately.
> > To try it out I do in a console:
> >
> > crm_shadow --create test
> > crm_attribute --type nodes --node node-0 --name my-attribute
> > --update 1 --lifetime=reboot
> >
> > And this attribute is set to the live cluster configuration 
> immediately.
> > What am I doing wrong?
> >
> > Thank you,
> > Kostia
> >
> > On Tue, Nov 22, 2016 at 11:33 PM, Kostiantyn Ponomarenko
> >  
> >  >> wrote:
> >
> > Ken,
> > Thank you for the explanation.
> > I will try this low-level way of shadow cib creation tomorrow.
> > PS: I will sleep much better with this excellent news/idea. =)
> >
> > Thank you,
> > Kostia
> >
> > On Tue, Nov 22, 2016 at 10:53 PM, Ken Gaillot
> > 
> >> wrote:
> >
> > On 11/22/2016 04:39 AM, Kostiantyn Ponomarenko wrote:
> > > Using "shadow cib" in crmsh looks like a good idea, but 
> it doesn't work
> > > with node attributes set into "status" section of 
> Pacemaker config.
> > > I wonder it it is possible to make it work that way.
> >
> > Forgot to mention -- the shadow CIB is probably the best way
> > to do this.
> > I don't know if there's a way to do it in crmsh, but you can
> > use it with
> > the

[ClusterLabs] Pacemaker 1.1.16 released

2016-11-30 Thread Ken Gaillot 
ClusterLabs is proud to announce the latest release of the Pacemaker
cluster resource manager, version 1.1.15. The source code is available at:

https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1.16
The most significant enhancements in this release are:

* rsc-pattern may now be used instead of rsc in location constraints, to
allow a single location constraint to apply to all resources whose names
match a regular expression. Sed-like %0 - %9 backreferences let
submatches be used in node attribute names in rules.

* The new ocf:pacemaker:attribute resource agent sets a node attribute
according to whether the resource is running or stopped. This may be
useful in combination with attribute-based rules to model dependencies
that simple constraints can't handle.

* Pacemaker's existing "node health" feature allows resources to move
off nodes that become unhealthy. Now, when using
node-health-strategy=progressive, a new cluster property
node-health-base will be used as the initial health score of newly
joined nodes (defaulting to 0, which is the previous behavior). This
allows a node to be treated as "healthy" even if it has some "yellow"
health attributes, which can be useful to allow clones to run on such nodes.

* Previously, the OCF_RESKEY_CRM_meta_notify_active_* variables were not
properly passed to multistate resources with notification enabled. This
has been fixed. To help resource agents detect when the fix is
available, the CRM feature set has been incremented. (Whenever the
feature set changes, mixed-version clusters are supported only during
rolling upgrades -- nodes with an older version will not be allowed to
rejoin once they shut down.)

* Watchdog-based fencing using sbd now works better on remote nodes.
This capability still likely has some limitations, however.

* The build process now takes advantage of various compiler features
(RELRO, PIE, as-needed linking, etc.) that enhance security and start-up
performance. See the "Hardening flags" comments in the configure.ac file
for more details.

* Python 3 compatibility: The Pacemaker project now targets
compatibility with both python 2 (versions 2.6 and later) and python 3
(versions 3.2 and later). All of the project's python code now meets
this target, with the exception of CTS, which is still python 2 only.

* The Pacemaker coding guidelines have been replaced by a more
comprehensive addition to the documentation set, "Pacemaker
Development". It is intended for developers working on the Pacemaker
code base itself, rather than external code such as resource agents. A
copy is viewable at
http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Development/

As usual, the release includes many bugfixes, including a fix for a
serious security vulnerability (CVE-2016-7035). For a more detailed list
of changes, see the change log:

https://github.com/ClusterLabs/pacemaker/blob/1.1/ChangeLog

Many thanks to all contributors of source code to this release,
including Andrew Beekhof, Bin Liu, Christian Schneider, Christoph Berg,
David Shane Holden, Ferenc Wágner, Yan Gao, Hideo Yamauchi, Jan Pokorný,
Ken Gaillot, Klaus Wenninger, Kostiantyn Ponomarenko, Kristoffer
Grönlund, Lars Ellenberg, Masatake Yamato, Michal Koutný, Nakahira
Kazutomo, Nate Clark, Nishanth Aravamudan, Oyvind Albrigtsen, Ruben
Kerkhof, Tim Bishop, Vladislav Bogdanov and Yusuke Iida. Apologies if I
have overlooked anyone.
-- 
Ken Gaillot 

___
Users mailing list: Users@clusterlabs.org
http://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

Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network segment

2016-11-30 Thread Dimitri Maziuk 
PS you could probably use iptables to block/log outgoing traffic from
the wrong ip (different on each node) to be really really sure.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Users mailing list: Users@clusterlabs.org
http://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

Re: [ClusterLabs] ocf:heartbeat:IPaddr2 - Different network segment

2016-11-30 Thread Dimitri Maziuk 
On 11/30/2016 09:10 AM, Ronny Machado C. wrote:
...any advice on how to
> use  ocf:heartbeat:IPaddr2 ip=x.x.x.x but in different segments, maybe is
> super easy, but  right now I can't find out how.

ICBW but if you bring up an ip in the wrong segment, it'll just be
unroutable/unreachable. As long as outgoing packets don't have it as
their from address, you should be fine.

I.e. just have both ips up on either node and see what happens.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



signature.asc
Description: OpenPGP digital signature
___
Users mailing list: Users@clusterlabs.org
http://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

Re: [ClusterLabs] Antw: Re: Set a node attribute for multiple nodes with one command

2016-11-30 Thread Kostiantyn Ponomarenko 
>> Moreover, when you delete this attribute the actual remove will be
delayed by that "--delay" which was used when the attribute was set.
I wasn't clear here. The behavior described in this line happens only when
"dampening" has worked out during the attribute set-up.

Thank you,
Kostia

On Wed, Nov 30, 2016 at 7:31 PM, Kostiantyn Ponomarenko <
konstantin.ponomare...@gmail.com> wrote:

> Hi Ken,
>
> I didn't look into the logs, but I experimented with it for a while.
> Here is what I found.
>
> It worked for you because this attribute - "my-attr" - has not ever been
> set before in that cluster.
>
> So if you set an attribute, then remove it, and then set it with
> "--delay", like:
>
> # attrd_updater -N node-0 -n my-attr --update false --delay 20
>
> , this delay (dampening) won't work.
> Moreover, when you delete this attribute the actual remove will be delayed
> by that "--delay" which was used when the attribute was set.
>
>
> Thank you,
> Kostia
>
> On Tue, Nov 29, 2016 at 1:08 AM, Ken Gaillot  wrote:
>
>> On 11/24/2016 05:24 AM, Kostiantyn Ponomarenko wrote:
>> > Attribute dampening doesn't work for me also.
>> > To test that I have a script:
>> >
>> > attrd_updater -N node-0 -n my-attr --update false --delay 20
>> > sleep 3
>> > attrd_updater -N node-0 -n my-attr --update true
>> > sleep 7
>> > attrd_updater -N node-1 -n my-attr --update true
>>
>> This sequence works for me -- the attributes are not written to the live
>> CIB until the end of the delay, when both are written at the same time.
>>
>> The remaining issue must be with the policy engine. You could look at
>> the detail log on the DC when these changes were made; you should see
>> info-level messages with the CIB change with both values together (lines
>> with "cib_perform_op:   ++" and the attribute values), then "Transition
>> aborted" with "Transient attribute change", then a bunch of "pengine:"
>> lines saying what the cluster wants to do with each resource.
>>
>> There should be some information about the scores used to place the
>> resources.
>>
>> >
>> > All my resources have this rule in Pacemaker config:
>> >
>> > crm configure location res1-location-rule res1 \
>> > rule 0: my-attr eq true \
>> > rule -inf: my-attr ne true
>> >
>> > On a working two-node cluster I remove "my-attr" from both nodes.
>> > Then run my script. And all resources start on node-0.
>> > Am I doing something wrong?
>> > Or maybe my understanding of an attribute dampening is not correct?
>> >
>> > My Pacemaker version is 1.1.13. (heh, not the last one, but it is what
>> > it is ...)
>> >
>> > Thank you,
>> > Kostia
>> >
>> > On Wed, Nov 23, 2016 at 7:27 PM, Kostiantyn Ponomarenko
>> > > > > wrote:
>> >
>> > Maybe I am doing something wrong, but I cannot set "status" section
>> > node attributes to a shadow cib, cluster applies them immediately.
>> > To try it out I do in a console:
>> >
>> > crm_shadow --create test
>> > crm_attribute --type nodes --node node-0 --name my-attribute
>> > --update 1 --lifetime=reboot
>> >
>> > And this attribute is set to the live cluster configuration
>> immediately.
>> > What am I doing wrong?
>> >
>> > Thank you,
>> > Kostia
>> >
>> > On Tue, Nov 22, 2016 at 11:33 PM, Kostiantyn Ponomarenko
>> > > > > wrote:
>> >
>> > Ken,
>> > Thank you for the explanation.
>> > I will try this low-level way of shadow cib creation tomorrow.
>> > PS: I will sleep much better with this excellent news/idea. =)
>> >
>> > Thank you,
>> > Kostia
>> >
>> > On Tue, Nov 22, 2016 at 10:53 PM, Ken Gaillot
>> > > wrote:
>> >
>> > On 11/22/2016 04:39 AM, Kostiantyn Ponomarenko wrote:
>> > > Using "shadow cib" in crmsh looks like a good idea, but
>> it doesn't work
>> > > with node attributes set into "status" section of
>> Pacemaker config.
>> > > I wonder it it is possible to make it work that way.
>> >
>> > Forgot to mention -- the shadow CIB is probably the best way
>> > to do this.
>> > I don't know if there's a way to do it in crmsh, but you can
>> > use it with
>> > the low-level commands crm_shadow and crm_attribute
>> > --lifetime=reboot.
>> >
>> > > Ken,
>> > >>> start dampening timer
>> > > Could you please elaborate more on this. I don't get how
>> I can set this
>> > > timer.
>> > > Do I need to set this timer for each node?
>> > >
>> > >
>> > > Thank you,
>> > > Kostia
>> > >
>> > > On Mon, Nov 21, 2016 at

Re: [ClusterLabs] Antw: Re: Set a node attribute for multiple nodes with one command

2016-11-30 Thread Kostiantyn Ponomarenko 
Hi Ken,

I didn't look into the logs, but I experimented with it for a while.
Here is what I found.

It worked for you because this attribute - "my-attr" - has not ever been
set before in that cluster.

So if you set an attribute, then remove it, and then set it with "--delay",
like:

# attrd_updater -N node-0 -n my-attr --update false --delay 20

, this delay (dampening) won't work.
Moreover, when you delete this attribute the actual remove will be delayed
by that "--delay" which was used when the attribute was set.


Thank you,
Kostia

On Tue, Nov 29, 2016 at 1:08 AM, Ken Gaillot  wrote:

> On 11/24/2016 05:24 AM, Kostiantyn Ponomarenko wrote:
> > Attribute dampening doesn't work for me also.
> > To test that I have a script:
> >
> > attrd_updater -N node-0 -n my-attr --update false --delay 20
> > sleep 3
> > attrd_updater -N node-0 -n my-attr --update true
> > sleep 7
> > attrd_updater -N node-1 -n my-attr --update true
>
> This sequence works for me -- the attributes are not written to the live
> CIB until the end of the delay, when both are written at the same time.
>
> The remaining issue must be with the policy engine. You could look at
> the detail log on the DC when these changes were made; you should see
> info-level messages with the CIB change with both values together (lines
> with "cib_perform_op:   ++" and the attribute values), then "Transition
> aborted" with "Transient attribute change", then a bunch of "pengine:"
> lines saying what the cluster wants to do with each resource.
>
> There should be some information about the scores used to place the
> resources.
>
> >
> > All my resources have this rule in Pacemaker config:
> >
> > crm configure location res1-location-rule res1 \
> > rule 0: my-attr eq true \
> > rule -inf: my-attr ne true
> >
> > On a working two-node cluster I remove "my-attr" from both nodes.
> > Then run my script. And all resources start on node-0.
> > Am I doing something wrong?
> > Or maybe my understanding of an attribute dampening is not correct?
> >
> > My Pacemaker version is 1.1.13. (heh, not the last one, but it is what
> > it is ...)
> >
> > Thank you,
> > Kostia
> >
> > On Wed, Nov 23, 2016 at 7:27 PM, Kostiantyn Ponomarenko
> >  > > wrote:
> >
> > Maybe I am doing something wrong, but I cannot set "status" section
> > node attributes to a shadow cib, cluster applies them immediately.
> > To try it out I do in a console:
> >
> > crm_shadow --create test
> > crm_attribute --type nodes --node node-0 --name my-attribute
> > --update 1 --lifetime=reboot
> >
> > And this attribute is set to the live cluster configuration
> immediately.
> > What am I doing wrong?
> >
> > Thank you,
> > Kostia
> >
> > On Tue, Nov 22, 2016 at 11:33 PM, Kostiantyn Ponomarenko
> >  > > wrote:
> >
> > Ken,
> > Thank you for the explanation.
> > I will try this low-level way of shadow cib creation tomorrow.
> > PS: I will sleep much better with this excellent news/idea. =)
> >
> > Thank you,
> > Kostia
> >
> > On Tue, Nov 22, 2016 at 10:53 PM, Ken Gaillot
> > > wrote:
> >
> > On 11/22/2016 04:39 AM, Kostiantyn Ponomarenko wrote:
> > > Using "shadow cib" in crmsh looks like a good idea, but it
> doesn't work
> > > with node attributes set into "status" section of
> Pacemaker config.
> > > I wonder it it is possible to make it work that way.
> >
> > Forgot to mention -- the shadow CIB is probably the best way
> > to do this.
> > I don't know if there's a way to do it in crmsh, but you can
> > use it with
> > the low-level commands crm_shadow and crm_attribute
> > --lifetime=reboot.
> >
> > > Ken,
> > >>> start dampening timer
> > > Could you please elaborate more on this. I don't get how I
> can set this
> > > timer.
> > > Do I need to set this timer for each node?
> > >
> > >
> > > Thank you,
> > > Kostia
> > >
> > > On Mon, Nov 21, 2016 at 9:30 AM, Ulrich Windl
> > >  > 
> > >  > >> wrote:
> > >
> > > >>> Ken Gaillot  >   > >>
> > > schrieb am 18.11.2016 um 16:17 in Nachricht
>

Re: [ClusterLabs] Get rid of reload altogether

2016-11-30 Thread Jan Pokorný 
On 28/11/16 09:44 +0530, Nikhil Utane wrote:
> I understand the whole concept of reload and how to define parameters with
> unique=0 so that pacemaker can call the reload operation of the OCF script
> instead of stopping and starting the resource.
> Now my problem is that I have 100s of parameters and I don't want to
> specify each of those with unique=0.

Would it be doable that your agent, when asked for metadata, will
produce them as usual, but in addition runs the XML through XSL
template that will add these unique=0 declarations for you
(except perhaps some whitelist)?

-- 
Jan (Poki)


pgpfSb3Fhd6kZ.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
http://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

[ClusterLabs] ocf:heartbeat:IPaddr2 - Different network segment

2016-11-30 Thread Ronny Machado C. 
Hi gurus,

soon I'll have to configure an Apache  web server cluster which publish a
VIP via ofc:hearbeat:IPaddr2, thing is, the two nodes live in different
sites and with a different ip segments...any advice on how to
use  ocf:heartbeat:IPaddr2 ip=x.x.x.x but in different segments, maybe is
super easy, but  right now I can't find out how.


Thanks in advance

*---*
*Ronny Machado C.*
*  ​IT Consultant​*
* +569 75199262*
*​* 
___
Users mailing list: Users@clusterlabs.org
http://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