Re: [ClusterLabs] Q: "Multiple attributes match name=target-role"
Hi Ulrich, Does this fix work for you? https://github.com/ClusterLabs/crmsh/pull/979 Regards, xin From: Users on behalf of Ulrich Windl Sent: Thursday, June 2, 2022 2:08 PM To: users@clusterlabs.org Subject: [ClusterLabs] Q: "Multiple attributes match name=target-role" Hi! We had some issue with a resource in SLES15 SP3, so I cleaned the error: h16:~ # crm_resource -C -r prm_xen_v07 -N h18 -n start Cleaned up prm_xen_v07 on h18 Multiple attributes match name=target-role Value: Started(id=prm_xen_v07-meta_attributes-target-role) Value: Started(id=prm_xen_v07-meta_attributes-0-target-role) Value: Started(id=prm_xen_v07-meta_attributes-1-target-role) There have always been multiple target roles in the past, but I never saw this complaint, making me woner whether a recent update introduced that feature. crmsh-4.3.1+20220505.cf4ab649-150200.5.80.1.noarch pacemaker-2.0.5+20201202.ba59be712-150300.4.21.1.x86_64 primitive prm_xen_v07 VirtualDomain \ params config="/etc/xen/vm/v07.xml" hypervisor="xen:///system" remoteuri="xen+tls://%n.uni-regensburg.de" autoset_utilization_cpu=false autoset_utilization_hv_memory=false \ op start timeout=120 interval=0 \ op stop timeout=240 interval=0 \ op monitor interval=600 timeout=90 \ op migrate_to timeout=120 interval=0 \ op migrate_from timeout=120 interval=0 \ utilization utl_cpu=20 utl_ram=2048 \ meta priority=8900 allow-migrate=true target-role=Started \ meta 1: resource-stickiness=5 target-role=Started \ meta 2: rule 0: date spec hours=7-19 weekdays=1-5 resource-stickiness=1000 target-role=Started AFAIR a crm resource start/stop set the target-role in every rule in the past. Finally: The resource is running fine on h16, but pacemaker keeps complaining it isn't started. Jun 02 08:03:21 h16 pacemaker-schedulerd[7494]: warning: Unexpected result (error: Failed to start virtual domain v07.) was recorded for start of prm_xen_v07 on h19 at Jun 1 09:19:46 2022 Jun 02 08:03:21 h16 pacemaker-schedulerd[7494]: warning: Forcing prm_xen_v07 away from h19 after 100 failures (max=100) Also it does not try to stop it there. Could it be that this is another effect of the RAM corruption introduced with SLES15 SP3? h16 is DC... Regards, Ulrich ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/ ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Q: "Multiple attributes match name=target-role"
Hi Ulrich, Yes, I remembered you mentioned this multi target-role issue https://github.com/ClusterLabs/crmsh/issues/720 From: Users on behalf of Ulrich Windl Sent: Thursday, June 2, 2022 2:08 PM To: users@clusterlabs.org Subject: [ClusterLabs] Q: "Multiple attributes match name=target-role" Hi! We had some issue with a resource in SLES15 SP3, so I cleaned the error: h16:~ # crm_resource -C -r prm_xen_v07 -N h18 -n start Cleaned up prm_xen_v07 on h18 Multiple attributes match name=target-role Value: Started(id=prm_xen_v07-meta_attributes-target-role) Value: Started(id=prm_xen_v07-meta_attributes-0-target-role) Value: Started(id=prm_xen_v07-meta_attributes-1-target-role) There have always been multiple target roles in the past, but I never saw this complaint, making me woner whether a recent update introduced that feature. crmsh-4.3.1+20220505.cf4ab649-150200.5.80.1.noarch pacemaker-2.0.5+20201202.ba59be712-150300.4.21.1.x86_64 primitive prm_xen_v07 VirtualDomain \ params config="/etc/xen/vm/v07.xml" hypervisor="xen:///system" remoteuri="xen+tls://%n.uni-regensburg.de" autoset_utilization_cpu=false autoset_utilization_hv_memory=false \ op start timeout=120 interval=0 \ op stop timeout=240 interval=0 \ op monitor interval=600 timeout=90 \ op migrate_to timeout=120 interval=0 \ op migrate_from timeout=120 interval=0 \ utilization utl_cpu=20 utl_ram=2048 \ meta priority=8900 allow-migrate=true target-role=Started \ meta 1: resource-stickiness=5 target-role=Started \ meta 2: rule 0: date spec hours=7-19 weekdays=1-5 resource-stickiness=1000 target-role=Started AFAIR a crm resource start/stop set the target-role in every rule in the past. Finally: The resource is running fine on h16, but pacemaker keeps complaining it isn't started. Jun 02 08:03:21 h16 pacemaker-schedulerd[7494]: warning: Unexpected result (error: Failed to start virtual domain v07.) was recorded for start of prm_xen_v07 on h19 at Jun 1 09:19:46 2022 Jun 02 08:03:21 h16 pacemaker-schedulerd[7494]: warning: Forcing prm_xen_v07 away from h19 after 100 failures (max=100) Also it does not try to stop it there. Could it be that this is another effect of the RAM corruption introduced with SLES15 SP3? h16 is DC... Regards, Ulrich ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/ ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Q: "Multiple attributes match name=target-role"
Hi! We had some issue with a resource in SLES15 SP3, so I cleaned the error: h16:~ # crm_resource -C -r prm_xen_v07 -N h18 -n start Cleaned up prm_xen_v07 on h18 Multiple attributes match name=target-role Value: Started(id=prm_xen_v07-meta_attributes-target-role) Value: Started(id=prm_xen_v07-meta_attributes-0-target-role) Value: Started(id=prm_xen_v07-meta_attributes-1-target-role) There have always been multiple target roles in the past, but I never saw this complaint, making me woner whether a recent update introduced that feature. crmsh-4.3.1+20220505.cf4ab649-150200.5.80.1.noarch pacemaker-2.0.5+20201202.ba59be712-150300.4.21.1.x86_64 primitive prm_xen_v07 VirtualDomain \ params config="/etc/xen/vm/v07.xml" hypervisor="xen:///system" remoteuri="xen+tls://%n.uni-regensburg.de" autoset_utilization_cpu=false autoset_utilization_hv_memory=false \ op start timeout=120 interval=0 \ op stop timeout=240 interval=0 \ op monitor interval=600 timeout=90 \ op migrate_to timeout=120 interval=0 \ op migrate_from timeout=120 interval=0 \ utilization utl_cpu=20 utl_ram=2048 \ meta priority=8900 allow-migrate=true target-role=Started \ meta 1: resource-stickiness=5 target-role=Started \ meta 2: rule 0: date spec hours=7-19 weekdays=1-5 resource-stickiness=1000 target-role=Started AFAIR a crm resource start/stop set the target-role in every rule in the past. Finally: The resource is running fine on h16, but pacemaker keeps complaining it isn't started. Jun 02 08:03:21 h16 pacemaker-schedulerd[7494]: warning: Unexpected result (error: Failed to start virtual domain v07.) was recorded for start of prm_xen_v07 on h19 at Jun 1 09:19:46 2022 Jun 02 08:03:21 h16 pacemaker-schedulerd[7494]: warning: Forcing prm_xen_v07 away from h19 after 100 failures (max=100) Also it does not try to stop it there. Could it be that this is another effect of the RAM corruption introduced with SLES15 SP3? h16 is DC... Regards, Ulrich ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
