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 <kgail...@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.ponomare...@gmail.com > > <mailto: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 > > <mailto: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 > > <kgail...@redhat.com <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 > > > <ulrich.wi...@rz.uni-regensburg.de > > <mailto:ulrich.wi...@rz.uni-regensburg.de> > > > <mailto:ulrich.wi...@rz.uni-regensburg.de > > <mailto:ulrich.wi...@rz.uni-regensburg.de>>> wrote: > > > > > > >>> Ken Gaillot <kgail...@redhat.com > > <mailto:kgail...@redhat.com> <mailto:kgail...@redhat.com > > <mailto:kgail...@redhat.com>>> > > > schrieb am 18.11.2016 um 16:17 in Nachricht > > > <d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com> > > > > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@redhat.com > > <mailto:d6f449da-64f8-12ad-00be-e772d8e38...@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. >
_______________________________________________ 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