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

2016-12-01 Thread Kostiantyn Ponomarenko 
Thank you for the comprehensive answer. =)

Thank you,
Kostia

On Thu, Dec 1, 2016 at 5:56 PM, Ken Gaillot  wrote:

> 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:
> >

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

2016-12-01 Thread 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 script. And all resources start on node-0.
>

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

2016-12-01 Thread 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 Tue, Nov 22, 2016 at 10:53 PM, Ken Gaillot
> > > mailto:kgail...@redhat.com>
> >

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
> > mailto:kgail...@redhat.com>
> >> 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.
> >
> >

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
>> > mailto:kgail...@redhat.com>> 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
>> > > > > 
>> >

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
> > mailto:kgail...@redhat.com>> 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] Antw: Re: Set a node attribute for multiple nodes with one command

2016-11-28 Thread Ken Gaillot 
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
> mailto:kgail...@redhat.com>> 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
> >  
> >   
>   >>:
> > > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
> > >> Hi folks,
> > >>
> > >> Is there a way to set a node attribute to the
> "status" section for few
> > >> nodes at the same time?
> > >>
> > >> In my case there is a node attribute which allows
> some resources to
> > >> start in the cluster if it is set.
> > >> If I set this node attribute for say two nodes in a
> way - one and then
> > >> another, than these resources are not distributed
> equally between these
> >

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

2016-11-28 Thread Ken Gaillot 
On 11/23/2016 11:27 AM, 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?

Strange ... if you use --lifetime=forever, it's recorded in the shadow
CIB, but if you use --lifetime=reboot, it's recorded in the live CIB.
That looks like a bug to me; I'll make a note to investigate.

> 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
> >  
> >  >>:
> > > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
> > >> Hi folks,
> > >>
> > >> Is there a way to set a node attribute to the "status"
> section for few
> > >> nodes at the same time?
> > >>
> > >> In my case there is a node attribute which allows some
> resources to
> > >> start in the cluster if it is set.
> > >> If I set this node attribute for say two nodes in a way
> - one and then
> > >> another, than these resources are not distributed
> equally between these
> > >> two nodes. That because Pacemaker picks the first node
> to with this
> > >> attribute is set and immediately starts all allowed
> resources on it. And
> > >> this is not the behavior i would like to get.
> > >>
> > >> Thank you,
> > >> Kostia
> > >
> > > Not that I know of, but it would be a good feature to add to
> > > attrd_updater and/or crm_attribute.
> >
> > With crm (shell) you don't have transactions for node
> attributes,
> > but for the configuration. So if you add a location
> restriction
> > preventing any resources on your nodes, then enable the
> nodes, and
> > then delete the location restrictions in one transaction,
> you might
> > get what you want. It's not elegant, but itt ill do.
> >
> > To the crm shell maintainer: Is is difficult to build
> transactions
> > to node status changes? The problem I see is this: For
> configuration
> > you always have transactions (requiring "commit), but for
> nodes you
> > traditionally have non (effects are immediate). So you'd
> need a
> > thing like "start transaction" which requires a "commit"
> or some
> > kind of abort later.
> >
> > I also don't know whether a "shadow CIB" would help for
> the original
> > problem.
> >
> > Ulrich
> >
> > >
> > > You can probably hack it wi

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

2016-11-24 Thread Kostiantyn Ponomarenko 
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

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 <
konstantin.ponomare...@gmail.com> 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 <
> konstantin.ponomare...@gmail.com> 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 mailto:kgail...@redhat.com>>
>>> > schrieb am 18.11.2016 um 16:17 in Nachricht
>>> > >> > >:
>>> > > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
>>> > >> Hi folks,
>>> > >>
>>> > >> Is there a way to set a node attribute to the "status" section
>>> for few
>>> > >> nodes at the same time?
>>> > >>
>>> > >> In my case there is a node attribute which allows some
>>> resources to
>>> > >> start in the cluster if it is set.
>>> > >> If I set this node attribute for say two nodes in a way - one
>>> and then
>>> > >> another, than these resources are not distributed equally
>>> between these
>>> > >> two nodes. That because Pacemaker picks the first node to with
>>> this
>>> > >> attribute is set and immediately starts all allowed resources
>>> on it. And
>>> > >> this is not the behavior i would like to get.
>>> > >>
>>> > >> Thank you,
>>> > >> Kostia
>>> > >
>>> > > Not that I know of, but it would be a good feature to add to
>>> > > attrd_updater and/or crm_attribute.
>>> >
>>> > With crm (shell) you don't have transactions for node attributes,
>>> > but for the configuration. So if you add a location restriction
>>> > preventing any resources on your nodes, then enable the nodes, and
>>> > then delete the location restrictions in one transaction, you might
>>> > get what you want. It's not elegant, but itt ill do.
>>> >
>>> > To the crm shell maintainer: Is is difficult to build transactions
>>> > to node status changes? The problem I see is this: For
>>> configuration
>>> > you always have transactions (requiring "commit), but for nodes you
>>> > traditionally have non (effects are immediate). So you'd need a
>>> > thing like "start transaction" which requires a "commit" or some
>>> > kind of abort later.
>>> >
>>> > I also don't know whether a "shadow CIB" would help for the
>>> original
>>> > problem.
>>> >
>>> > Ulrich
>>> >
>>> > >
>>> > > You can probably hack it with a dampening value of a few
>>> seconds. If
>>> > > your rule checks for a particular value of the attribute, set
>>> all the
>>> > > nodes to a different value first, which will write that value and
>>> > start
>>> > > the dampening timer. Then set all the attributes to the desired
>>> value,
>>> >

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

2016-11-23 Thread Kostiantyn Ponomarenko 
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 <
konstantin.ponomare...@gmail.com> 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 mailto:kgail...@redhat.com>>
>> > schrieb am 18.11.2016 um 16:17 in Nachricht
>> > > > >:
>> > > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
>> > >> Hi folks,
>> > >>
>> > >> Is there a way to set a node attribute to the "status" section
>> for few
>> > >> nodes at the same time?
>> > >>
>> > >> In my case there is a node attribute which allows some resources
>> to
>> > >> start in the cluster if it is set.
>> > >> If I set this node attribute for say two nodes in a way - one
>> and then
>> > >> another, than these resources are not distributed equally
>> between these
>> > >> two nodes. That because Pacemaker picks the first node to with
>> this
>> > >> attribute is set and immediately starts all allowed resources on
>> it. And
>> > >> this is not the behavior i would like to get.
>> > >>
>> > >> Thank you,
>> > >> Kostia
>> > >
>> > > Not that I know of, but it would be a good feature to add to
>> > > attrd_updater and/or crm_attribute.
>> >
>> > With crm (shell) you don't have transactions for node attributes,
>> > but for the configuration. So if you add a location restriction
>> > preventing any resources on your nodes, then enable the nodes, and
>> > then delete the location restrictions in one transaction, you might
>> > get what you want. It's not elegant, but itt ill do.
>> >
>> > To the crm shell maintainer: Is is difficult to build transactions
>> > to node status changes? The problem I see is this: For configuration
>> > you always have transactions (requiring "commit), but for nodes you
>> > traditionally have non (effects are immediate). So you'd need a
>> > thing like "start transaction" which requires a "commit" or some
>> > kind of abort later.
>> >
>> > I also don't know whether a "shadow CIB" would help for the original
>> > problem.
>> >
>> > Ulrich
>> >
>> > >
>> > > You can probably hack it with a dampening value of a few seconds.
>> If
>> > > your rule checks for a particular value of the attribute, set all
>> the
>> > > nodes to a different value first, which will write that value and
>> > start
>> > > the dampening timer. Then set all the attributes to the desired
>> value,
>> > > and they will get written out together when the timer expires.
>>
>
>
___
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-22 Thread Kostiantyn Ponomarenko 
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 mailto:kgail...@redhat.com>>
> > schrieb am 18.11.2016 um 16:17 in Nachricht
> >  > >:
> > > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
> > >> Hi folks,
> > >>
> > >> Is there a way to set a node attribute to the "status" section
> for few
> > >> nodes at the same time?
> > >>
> > >> In my case there is a node attribute which allows some resources
> to
> > >> start in the cluster if it is set.
> > >> If I set this node attribute for say two nodes in a way - one and
> then
> > >> another, than these resources are not distributed equally between
> these
> > >> two nodes. That because Pacemaker picks the first node to with
> this
> > >> attribute is set and immediately starts all allowed resources on
> it. And
> > >> this is not the behavior i would like to get.
> > >>
> > >> Thank you,
> > >> Kostia
> > >
> > > Not that I know of, but it would be a good feature to add to
> > > attrd_updater and/or crm_attribute.
> >
> > With crm (shell) you don't have transactions for node attributes,
> > but for the configuration. So if you add a location restriction
> > preventing any resources on your nodes, then enable the nodes, and
> > then delete the location restrictions in one transaction, you might
> > get what you want. It's not elegant, but itt ill do.
> >
> > To the crm shell maintainer: Is is difficult to build transactions
> > to node status changes? The problem I see is this: For configuration
> > you always have transactions (requiring "commit), but for nodes you
> > traditionally have non (effects are immediate). So you'd need a
> > thing like "start transaction" which requires a "commit" or some
> > kind of abort later.
> >
> > I also don't know whether a "shadow CIB" would help for the original
> > problem.
> >
> > Ulrich
> >
> > >
> > > You can probably hack it with a dampening value of a few seconds.
> If
> > > your rule checks for a particular value of the attribute, set all
> the
> > > nodes to a different value first, which will write that value and
> > start
> > > the dampening timer. Then set all the attributes to the desired
> value,
> > > and they will get written out together when the timer expires.
>
___
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-22 Thread Ken Gaillot 
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 mailto:kgail...@redhat.com>>
> schrieb am 18.11.2016 um 16:17 in Nachricht
>  >:
> > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
> >> Hi folks,
> >>
> >> Is there a way to set a node attribute to the "status" section for few
> >> nodes at the same time?
> >>
> >> In my case there is a node attribute which allows some resources to
> >> start in the cluster if it is set.
> >> If I set this node attribute for say two nodes in a way - one and then
> >> another, than these resources are not distributed equally between these
> >> two nodes. That because Pacemaker picks the first node to with this
> >> attribute is set and immediately starts all allowed resources on it. 
> And
> >> this is not the behavior i would like to get.
> >>
> >> Thank you,
> >> Kostia
> >
> > Not that I know of, but it would be a good feature to add to
> > attrd_updater and/or crm_attribute.
> 
> With crm (shell) you don't have transactions for node attributes,
> but for the configuration. So if you add a location restriction
> preventing any resources on your nodes, then enable the nodes, and
> then delete the location restrictions in one transaction, you might
> get what you want. It's not elegant, but itt ill do.
> 
> To the crm shell maintainer: Is is difficult to build transactions
> to node status changes? The problem I see is this: For configuration
> you always have transactions (requiring "commit), but for nodes you
> traditionally have non (effects are immediate). So you'd need a
> thing like "start transaction" which requires a "commit" or some
> kind of abort later.
> 
> I also don't know whether a "shadow CIB" would help for the original
> problem.
> 
> Ulrich
> 
> >
> > You can probably hack it with a dampening value of a few seconds. If
> > your rule checks for a particular value of the attribute, set all the
> > nodes to a different value first, which will write that value and
> start
> > the dampening timer. Then set all the attributes to the desired value,
> > and they will get written out together when the timer expires.

___
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-22 Thread Ken Gaillot 
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.
> 
> 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?

Dampening is per attribute, so it applies to all nodes. You can set it
when you first create the attribute:

  attrd_updater -n $NAME --update $VALUE --delay $SECONDS

With dampening (delay), the attribute daemon will wait that long between
writes to the CIB. The goal is to reduce I/O activity for frequently
changing attributes, but it could also be handy here.


The --delay will be ignored if the above command is run after the
attribute already exists. You can change it for an already existing
attribute with

  attrd_updater -n $NAME --update-delay --delay $SECONDS

or

  attrd_updater -n $NAME --update-both $VALUE --delay $SECONDS


It's intentionally more trouble to set it on an already-created
attribute, because repeatedly changing the delay will make it useless
(each delay change requires an immediate write). Having a separate
command makes it less likely to be accidental.

> 
> 
> Thank you,
> Kostia
> 
> On Mon, Nov 21, 2016 at 9:30 AM, Ulrich Windl
>  > wrote:
> 
> >>> Ken Gaillot mailto:kgail...@redhat.com>>
> schrieb am 18.11.2016 um 16:17 in Nachricht
>  >:
> > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
> >> Hi folks,
> >>
> >> Is there a way to set a node attribute to the "status" section for few
> >> nodes at the same time?
> >>
> >> In my case there is a node attribute which allows some resources to
> >> start in the cluster if it is set.
> >> If I set this node attribute for say two nodes in a way - one and then
> >> another, than these resources are not distributed equally between these
> >> two nodes. That because Pacemaker picks the first node to with this
> >> attribute is set and immediately starts all allowed resources on it. 
> And
> >> this is not the behavior i would like to get.
> >>
> >> Thank you,
> >> Kostia
> >
> > Not that I know of, but it would be a good feature to add to
> > attrd_updater and/or crm_attribute.
> 
> With crm (shell) you don't have transactions for node attributes,
> but for the configuration. So if you add a location restriction
> preventing any resources on your nodes, then enable the nodes, and
> then delete the location restrictions in one transaction, you might
> get what you want. It's not elegant, but itt ill do.
> 
> To the crm shell maintainer: Is is difficult to build transactions
> to node status changes? The problem I see is this: For configuration
> you always have transactions (requiring "commit), but for nodes you
> traditionally have non (effects are immediate). So you'd need a
> thing like "start transaction" which requires a "commit" or some
> kind of abort later.
> 
> I also don't know whether a "shadow CIB" would help for the original
> problem.
> 
> Ulrich
> 
> >
> > You can probably hack it with a dampening value of a few seconds. If
> > your rule checks for a particular value of the attribute, set all the
> > nodes to a different value first, which will write that value and
> start
> > the dampening timer. Then set all the attributes to the desired value,
> > and they will get written out together when the timer expires.

___
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-22 Thread Kostiantyn Ponomarenko 
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.

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 <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Ken Gaillot  schrieb am 18.11.2016 um 16:17 in
> Nachricht
> :
> > On 11/18/2016 08:55 AM, Kostiantyn Ponomarenko wrote:
> >> Hi folks,
> >>
> >> Is there a way to set a node attribute to the "status" section for few
> >> nodes at the same time?
> >>
> >> In my case there is a node attribute which allows some resources to
> >> start in the cluster if it is set.
> >> If I set this node attribute for say two nodes in a way - one and then
> >> another, than these resources are not distributed equally between these
> >> two nodes. That because Pacemaker picks the first node to with this
> >> attribute is set and immediately starts all allowed resources on it. And
> >> this is not the behavior i would like to get.
> >>
> >> Thank you,
> >> Kostia
> >
> > Not that I know of, but it would be a good feature to add to
> > attrd_updater and/or crm_attribute.
>
> With crm (shell) you don't have transactions for node attributes, but for
> the configuration. So if you add a location restriction preventing any
> resources on your nodes, then enable the nodes, and then delete the
> location restrictions in one transaction, you might get what you want. It's
> not elegant, but itt ill do.
>
> To the crm shell maintainer: Is is difficult to build transactions to node
> status changes? The problem I see is this: For configuration you always
> have transactions (requiring "commit), but for nodes you traditionally have
> non (effects are immediate). So you'd need a thing like "start transaction"
> which requires a "commit" or some kind of abort later.
>
> I also don't know whether a "shadow CIB" would help for the original
> problem.
>
> Ulrich
>
> >
> > You can probably hack it with a dampening value of a few seconds. If
> > your rule checks for a particular value of the attribute, set all the
> > nodes to a different value first, which will write that value and start
> > the dampening timer. Then set all the attributes to the desired value,
> > and they will get written out together when the timer expires.
> >
> > ___
> > 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
>
>
>
>
>
> ___
> 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
>
___
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