Bug 1568353 - "pcs resource update" should not create an empty meta-attributes element
Summary: "pcs resource update" should not create an empty meta-attributes element
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.5
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-17 10:32 UTC by Tomas Jelinek
Modified: 2018-10-30 08:07 UTC (History)
8 users (show)

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"
Clone Of:
Environment:
Last Closed: 2018-10-30 08:06:06 UTC
Target Upstream Version:


Attachments (Terms of Use)
proposed fix (1.26 KB, patch)
2018-04-17 10:47 UTC, Tomas Jelinek
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1561617 0 urgent CLOSED crm_diff shows diffs even when it shouldn't 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1598197 0 urgent CLOSED Updating a bundle is a bit cumbersome 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2018:3066 0 None None None 2018-10-30 08:07:26 UTC

Internal Links: 1561617 1598197

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


Note You need to log in before you can comment on or make changes to this bug.