Re: [ClusterLabs] standby and unstandby commands

[Jan Pokorný]

On 29/11/16 08:24 +0100, Ulrich Windl wrote:
> Some servers first fork and exit, virtually being successful
> immediately, while the child (the "server loop") could die a moment
> later. Finding the perfect time to wait for the server dying is kind
> of black magic ;-)

That's exactly why I thing that's one of the aspects systemd moved
service startup design a step forward with its "notify" type of service
-- only the daemon author is fully capable/educated to narrow down
the exact point in the daemon's life cycle where it's supposed to
be "fully up, ready to service", marking that place with sd_notify(3)
call.  Everything else is just a heuristic, sometimes unreliable.

-- 
Jan (Poki)


pgpBSDOK0BrM1.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] @ClusterLabs/devel COPR with new pacemaker (Was: Pacemaker 1.1.16 released)

[Jan Pokorný]

On 30/11/16 14:05 -0600, Ken Gaillot wrote:
> 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

In the same vein as recent libqb release followup[1], but I promise I'll
refrain myself from further such crossover announcements, at least
regarding these two packages and unless there's a catch such as
the current one...

For those interested in Fedora/EL-based distros, I am happy to
announce that pacemaker became another citizen in the package set
under the @ClusterLabs/devel COPR repository[2], following the
previously declared example of libqb.  As a recap, this means that
new builds will be triggered upon new pushes arriving upstream,
which brings some advantages:

- curious users can play with new features early; they still should
  keep in mind that the only party interested in the bug reports
  for these otherwise throwaway byproducts are upstream developers,
  and only if the issue is relevant to recent changes

- such pacemaker builds will always be exercised upon the newest
  (buildable) libqb at that time, meaning the compilations issues
  arising from mutual incompatibilities should be spotted the soonest
  moment possible[*], preventing later surprises ([2] also states
  some examples that could have been discovered earlier)


And now back to how to obtain such bare upstream 1.1.16 version of
pacemaker from here (e.g., proper Fedora release will follow soon)
instantly.  As initially mentioned there's a catch, because there
are some discrepancies yet to be straightened out[3], so once the
mentioned COPR repo enabled (see [1] or [2]),

dnf update pacemaker-1.1.16-1$(rpm -E %dist)

won't help.  But because Pacemaker-1.1.16 tag is just another name
for 94ff4df commit for which the build was triggered prior to tag
being pushed, this build succeeded and can be hence used as

dnf update pacemaker-1.1.16-0.12.94ff4df.git$(rpm -E %dist)

(Admittedly, corrected build for 1.1.16 could be issued, but that
that would be completely redundant modulo RPM package metadata.)

Things should be in better shape for the next release :-)

  
[*] putting the test compilations proactively run by the contributors
of either project aside, as that hardly scales in any meaningful way

[1] http://lists.clusterlabs.org/pipermail/users/2016-November/004590.html
[2] https://copr.fedorainfracloud.org/coprs/g/ClusterLabs/devel/
[3] https://github.com/ClusterLabs/pacemaker/pull/1196

-- 
Jan (Poki)


pgpVpSmx2NEzs.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

Re: [ClusterLabs] Pacemaker 1.1.16 released

[Jehan-Guillaume de Rorthais]

Le 1 décembre 2016 17:39:45 GMT+01:00, Ken Gaillot  a 
écrit :
>On 12/01/2016 10:13 AM, Jehan-Guillaume de Rorthais wrote:
>> On Wed, 30 Nov 2016 14:05:19 -0600
>> Ken Gaillot  wrote:
>> 
>>> ClusterLabs is proud to announce the latest release of the Pacemaker
>>> cluster resource manager, version 1.1.15.
>> 
>> 1.1.6 I guess ;)
>
>Whoops!
>
>Well now I don't feel so bad since the correction is wrong too ;)

Argh !! :-D 

What about my questions bellow BTW ? :-P 

>> But congrats anyway !
>> 
>>> * 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.)
>> 
>>   * how could we get the "CRM feature set" version from the RA?
>>   * when this "CRM feature set" has been introduced in Pacemaker?
>> 
>> Regards,
>> 

-- 
Sent from my phone

___
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] Pacemaker 1.1.16 released

[Ken Gaillot]

On 12/01/2016 10:13 AM, Jehan-Guillaume de Rorthais wrote:
> On Wed, 30 Nov 2016 14:05:19 -0600
> Ken Gaillot  wrote:
> 
>> ClusterLabs is proud to announce the latest release of the Pacemaker
>> cluster resource manager, version 1.1.15.
> 
> 1.1.6 I guess ;)

Whoops!

Well now I don't feel so bad since the correction is wrong too ;)

> But congrats anyway !
> 
>> * 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.)
> 
>   * how could we get the "CRM feature set" version from the RA?
>   * when this "CRM feature set" has been introduced in Pacemaker?
> 
> Regards,
> 


___
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] Pacemaker 1.1.16 released

[Jehan-Guillaume de Rorthais]

On Wed, 30 Nov 2016 14:05:19 -0600
Ken Gaillot  wrote:

> ClusterLabs is proud to announce the latest release of the Pacemaker
> cluster resource manager, version 1.1.15.

1.1.6 I guess ;)

But congrats anyway !

> * 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.)

  * how could we get the "CRM feature set" version from the RA?
  * when this "CRM feature set" has been introduced in Pacemaker?

Regards,
-- 
Jehan-Guillaume de Rorthais
Dalibo

___
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

[Ken Gaillot]

On 12/01/2016 06:04 AM, Kostiantyn Ponomarenko wrote:
> OK, now I see. I still have a few questions.
> 1. Is there a good reason to not remove the attribute totally if it
> is "deleted"?

We do this for two reasons:

1. You can "delete" an attribute for just one node, while leaving it on
other nodes. Attrd needs to remember the attribute as a whole, and just
delete the value for the one node. Even deleting an attribute on all
nodes is done by separate deletes for each node, so this matters even then.

2. Information about the attribute needs to continue to exist in order
to reliably process changes from different nodes. I forget the exact
details, but I remember looking into it before.

These limitations could possibly be addressed by keeping the attribute
but setting a "deleted" flag, and changing how those would be reported,
but it's not on the radar right now.

> 2. Does "attrd_updater" sets attributes to "status" configuration
> section only?

Yes (when using corosync 2).

crm_attribute modifies the CIB directly, so there is no way to batch its
changes with a delay.

> 3. Do I need to modify/set "--delay" to 0 before removing or
> changing the attribute? Because now I see that previously set delay
> works when I delete the attribute (--delete).

It depends on what you want. The point of the delay is to write changes
out to the CIB only every so often, to save disk I/O. If you're
potentially changing attribute values several times per second, this
would be a huge performance boost. The delay affects all changes,
including deletes.

If you want a specific change to be written to the CIB immediately, then
yes, you have to set the delay to 0. You can either change the delay
beforehand with attrd_updater --update-delay or change the delay and
value together with --update-both.

> 4. Does a delay set only one time work until it's unset (set to 0)?

Yes

> Thank you,
> Kostia
> 
> On Wed, Nov 30, 2016 at 10:39 PM, Ken Gaillot  > wrote:
> 
> 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 

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

[Jan Pokorný]

On 30/11/16 12:10 -0300, Ronny Machado C. wrote:
> 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.

Not sure this is the optimal thing to do in this case, but have you
considered rule-based instance attributes?

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#_using_rules_to_control_resource_options

-- 
Jan (Poki)


pgpXWokLZ1E1i.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

Re: [ClusterLabs] Deleting a variable

[Ken Gaillot]

On 12/01/2016 01:15 AM, Ulrich Windl wrote:
 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

Not currently


___
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

[Kostiantyn Ponomarenko]

OK, now I see. I still have a few questions.
1. Is there a good reason to not remove the attribute totally if it is
"deleted"?
2. Does "attrd_updater" sets attributes to "status" configuration
section only?
3. Do I need to modify/set "--delay" to 0 before removing or changing
the attribute? Because now I see that previously set delay works when I
delete the attribute (--delete).
4. Does a delay set only one time work until it's unset (set to 0)?

Thank you,
Kostia

On Wed, Nov 30, 2016 at 10:39 PM, Ken Gaillot  wrote:

> 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