>> 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 < [email protected]> 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 <[email protected]> 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 >> > <[email protected] >> > <mailto:[email protected]>> 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 >> > <[email protected] >> > <mailto:[email protected]>> 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 >> > <[email protected] <mailto:[email protected]>> 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 >> > > <[email protected] >> > <mailto:[email protected]> >> > > <mailto:[email protected] >> > <mailto:[email protected]>>> wrote: >> > > >> > > >>> Ken Gaillot <[email protected] >> > <mailto:[email protected]> <mailto:[email protected] >> > <mailto:[email protected]>>> >> > > schrieb am 18.11.2016 um 16:17 in Nachricht >> > > <[email protected] >> > <mailto:[email protected]> >> > > >> > <mailto:[email protected] >> > <mailto:[email protected]>>>: >> > > > 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: [email protected] 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
