[ClusterLabs] Antw: Re: Set a node attribute for multiple nodes with one command
Kostiantyn Ponomarenko
konstantin.ponomarenko at gmail.com
Wed Nov 30 17:34:48 UTC 2016
>> 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.ponomarenko at 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 <kgaillot at redhat.com> 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
>> > <konstantin.ponomarenko at gmail.com
>> > <mailto:konstantin.ponomarenko at 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.ponomarenko at gmail.com
>> > <mailto:konstantin.ponomarenko at 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
>> > <kgaillot at redhat.com <mailto:kgaillot at 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
>> > > <Ulrich.Windl at rz.uni-regensburg.de
>> > <mailto:Ulrich.Windl at rz.uni-regensburg.de>
>> > > <mailto:Ulrich.Windl at rz.uni-regensburg.de
>> > <mailto:Ulrich.Windl at rz.uni-regensburg.de>>> wrote:
>> > >
>> > > >>> Ken Gaillot <kgaillot at redhat.com
>> > <mailto:kgaillot at redhat.com> <mailto:kgaillot at redhat.com
>> > <mailto:kgaillot at redhat.com>>>
>> > > schrieb am 18.11.2016 um 16:17 in Nachricht
>> > > <d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com
>> > <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com>
>> > >
>> > <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com
>> > <mailto:d6f449da-64f8-12ad-00be-e772d8e382ca at redhat.com>>>:
>> > > > 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20161130/baff7b67/attachment.htm>
More information about the Users
mailing list