Bug 1568353

Summary: "pcs resource update" should not create an empty meta-attributes element
Product: Red Hat Enterprise Linux 7 Reporter: Tomas Jelinek <tojeline>
Component: pcsAssignee: Tomas Jelinek <tojeline>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.5CC: cfeist, cluster-maint, idevat, jpokorny, omular, phagara, rsteiger, tojeline
Target Milestone: rcKeywords: EasyFix
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pcs-0.9.165-1.el7 Doc Type: Bug Fix
Doc Text:
Cause: The user runs the "pcs resource update" command on changing no meta attributes on a resource with no defined meta attributes. Consequence: An empty meta_attributes element is created in the CIB for the resource. Fix: Do not create an empty meta_attributes element on resource update. Result: An empty meta_attributes element is not created during "pcs resource update"
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 08:06:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed fix none

Description Tomas Jelinek 2018-04-17 10:32:32 UTC
Description of problem:
"pcs resource update" always creates a meta-attributes element in a resource being updated even if no meta-attributes are being added for the resource. This leads to crm_diff reporting a change of adding en empty meta-attributes element. When the output of crm_diff is used to figure out if there have been any changes in the CIB, this may lead to wrong assumption that a change have happened. However, from pacemaker point of view, adding an empty meta-attributes element is a noop. The solution here is not to create an empty meta-attributes element in pcs.


Version-Release number of selected component (if applicable):
pcs-0.9.162-5.el7_5.1


How reproducible:
always, easily


Steps to Reproduce:
1. pcs resource create dummy ocf:pacemaker:Dummy
2. check that no meta-attributes element exists
pcs cluster cib | grep -A 10 -m 1 'id="dummy"'
<primitive class="ocf" id="dummy" provider="pacemaker" type="Dummy">
  <operations>
    <op id="dummy-migrate_from-interval-0s" interval="0s" name="migrate_from" timeout="20"/>
    <op id="dummy-migrate_to-interval-0s" interval="0s" name="migrate_to" timeout="20"/>
    <op id="dummy-monitor-interval-10" interval="10" name="monitor" timeout="20"/>
    <op id="dummy-reload-interval-0s" interval="0s" name="reload" timeout="20"/>
    <op id="dummy-start-interval-0s" interval="0s" name="start" timeout="20"/>
    <op id="dummy-stop-interval-0s" interval="0s" name="stop" timeout="20"/>
  </operations>
</primitive>
</resources>
3. pcs resource update dummy fake=test
4. check the meta-attributes again


Actual results:
an empty meta-attributes element has been created
pcs cluster cib | grep -A 15 -m 1 'id="dummy"'
  <primitive class="ocf" id="dummy" provider="pacemaker" type="Dummy">
    <operations>
      <op id="dummy-migrate_from-interval-0s" interval="0s" name="migrate_from" timeout="20"/>
      <op id="dummy-migrate_to-interval-0s" interval="0s" name="migrate_to" timeout="20"/>
      <op id="dummy-monitor-interval-10" interval="10" name="monitor" timeout="20"/>
      <op id="dummy-reload-interval-0s" interval="0s" name="reload" timeout="20"/>
      <op id="dummy-start-interval-0s" interval="0s" name="start" timeout="20"/>
      <op id="dummy-stop-interval-0s" interval="0s" name="stop" timeout="20"/>
    </operations>
    <instance_attributes id="dummy-instance_attributes">
      <nvpair id="dummy-instance_attributes-fake" name="fake" value="test"/>
    </instance_attributes>
    <meta_attributes id="dummy-meta_attributes"/>
  </primitive>
</resources>
<constraints/>


Expected results:
no empty meta-attributes element has been created

Comment 1 Tomas Jelinek 2018-04-17 10:47:29 UTC
Created attachment 1422994 [details]
proposed fix

Comment 3 Jan Pokorný [poki] 2018-04-18 16:13:43 UTC
Note that "cibadmin --upgrade" will drop some of these "orphaned"
elements automatically, because that's how upgrade-2.10.xsl works.

Comment 4 Ivan Devat 2018-06-22 12:08:32 UTC
After Fix:

[ant ~] $ rpm -q pcs pcs-snmp
pcs-0.9.165-1.el7.x86_64
pcs-snmp-0.9.165-1.el7.x86_64

[ant ~] $ pcs resource create dummy ocf:pacemaker:Dummy
[ant ~] $ pcs cluster cib | grep -A 10 -m 1 'id="dummy"'|grep meta
[ant ~] $ pcs resource update dummy fake=test
[ant ~] $ pcs cluster cib | grep -A 10 -m 1 'id="dummy"'|grep meta
[ant ~] $

Comment 8 Jan Pokorný [poki] 2018-07-17 07:08:17 UTC
See also [bug 1598197 comment 6] for why doing the pruning part
(note this bug deals with just a tiny fraction of where it is in
fact applicable) and overall "canonicalization" of the modification
outcomes is important to keep the (possibibly accumulated) bit rot
away.  (That's also what CIB 2 -> 3 upgrade process autonomously
triggers for the parts it effectively touches in the course of the
upgrade, per [comment 3]).

Therefore might be worth (eventually) reviewing other similar parts
as well.

Comment 11 errata-xmlrpc 2018-10-30 08:06:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3066