RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1378107 - Misbehavior of the flag --master in "pcs resource create" command
Summary: Misbehavior of the flag --master in "pcs resource create" command
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Ivan Devat
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-21 13:43 UTC by Ivan Devat
Modified: 2018-03-13 15:27 UTC (History)
8 users (show)

Fixed In Version: pcs-0.9.156-1.el7
Doc Type: Bug Fix
Doc Text:
New syntax of "master" option in "pcs resource create" command allows correct creation of "meta" attributes Previously, when a "pcs" resource creation command included the "--master" flag, all options after the keyword "meta" were interpreted as master "meta" attributes. This made it impossible to create "meta" attributes for the primitive when the "--master" flag was specified. This fix provides a new syntax for specifying a resource as a master slave clone by using the following format for the command: pcs resource create resource_id standard:provider:type|type [resource options] master [master_options...] This allows you to specify "meta" options as follows: pcs resource create resource_id standard:provider:type|type [resource_options] meta meta_options... master [master_options...] Additionally, with this fix, you specify a clone resource with the "clone" option rather than the "--clone" flag, as in previous releases. The new format for specifying a clone resource is as follows: pcs resource create resource_id standard:provider:type|type [resource_options] clone
Clone Of:
Environment:
Last Closed: 2017-08-01 18:22:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proposed fix (36.33 KB, patch)
2017-01-31 14:22 UTC, Ivan Devat 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1395226 0 medium CLOSED Misbehavior of the flag --clone in "pcs resource create" command 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1458153 0 urgent CLOSED pcs 0.9.158 breaks resource creation with meta-attribute 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2017:1958 0 normal SHIPPED_LIVE pcs bug fix and enhancement update 2017-08-01 18:09:47 UTC

Internal Links: 1395226 1458153

Description Ivan Devat 2016-09-21 13:43:45 UTC 
Description of problem:
Flag --master in command "pcs resource create" does not act consistently in more ways.

> 1) Options after flag --master in command "pcs resource create" are interpreted inconsistently.
Besides master meta atributes (which is intended) they are used as primitive resouce options (a) and operation attributes (b) - in this case is invalid cib.

> a) Options after flag --master in command "pcs resource create" interpreted as primitive resource options

How reproducible: always


Steps to Reproduce:
[vm-rhel72-1 ~] $ pcs resource create dummy Dummy state=a --master is-managed=false --force


Actual results:

[vm-rhel72-1 ~] $ pcs cluster cib
...
<master id="dummy-master">
  <primitive class="ocf" id="dummy" provider="heartbeat" type="Dummy">
    <instance_attributes id="dummy-instance_attributes">
      <nvpair id="dummy-instance_attributes-state" name="state" value="a"/>
      <nvpair id="dummy-instance_attributes-is-managed" name="is-managed" value="false"/>
    </instance_attributes>
    <operations>
      <op id="dummy-monitor-interval-60s" interval="60s" name="monitor"/>
    </operations>
  </primitive>
</master>
...


Expected results:
[vm-rhel72-1 ~] $ pcs cluster cib
...
<master id="dummy-master">
  <primitive class="ocf" id="dummy" provider="heartbeat" type="Dummy">
    <instance_attributes id="dummy-instance_attributes">
      <nvpair id="dummy-instance_attributes-state" name="state" value="a"/>
    </instance_attributes>
    <operations>
      <op id="dummy-monitor-interval-60s" interval="60s" name="monitor"/>
    </operations>
  </primitive>
  <meta_attributes id="dummy-master-meta_attributes">
    <nvpair id="dummy-master-meta_attributes-is-managed" name="is-managed" value="false"/>
  </meta_attributes>
</master>
...

> b) Options after flag --master in command "pcs resource create" interpreted as operation options

How reproducible: always


Steps to Reproduce:
[vm-rhel72-1 ~] $ pcs resource create dummy Dummy state=a op monitor interval=10s --master fake=b --no-default-ops  --force

Actual results:
Error: Unable to update cib
Call cib_replace failed (-203): Update does not conform to the configured schema
...
<master id="dummy-master">
  <primitive class="ocf" id="dummy" provider="heartbeat" type="Dummy">
    <instance_attributes id="dummy-instance_attributes">
      <nvpair id="dummy-instance_attributes-state" name="state" value="a"/>
    </instance_attributes>
    <operations>
      <op fake="b" id="dummy-monitor-interval-10s" interval="10s" name="monitor"/>
    </operations>
  </primitive>
</master>
...


Expected results:
[vm-rhel72-1 ~] $ pcs cluster cib
...
<master id="dummy-master">
  <primitive class="ocf" id="dummy" provider="heartbeat" type="Dummy">
    <instance_attributes id="dummy-instance_attributes">
      <nvpair id="dummy-instance_attributes-state" name="state" value="a"/>
    </instance_attributes>
    <operations>
      <op id="dummy-monitor-interval-10s" interval="10s" name="monitor"/>
    </operations>
  </primitive>
  <meta_attributes id="dummy-master-meta_attributes">
    <nvpair id="dummy-master-meta_attributes-fake" name="fake" value="b"/>
  </meta_attributes>
</master>
...


> 2) Options after keyword meta are interpreted as master meta atributes when flag --master is present.
This behaviour occurs always, no regardless of how are interpreted options after flag --master (see point 1). This makes impossible create meta attributes in primitive when flag --master is used.


How reproducible: always


Steps to Reproduce:
[vm-rhel72-1 ~] $ pcs resource create dummy Dummy meta a=b --master b=c --no-default-ops


Actual results:
[vm-rhel72-1 ~] $ pcs cluster cib
...
<master id="dummy-master">
  <primitive class="ocf" id="dummy" provider="heartbeat" type="Dummy">
    <instance_attributes id="dummy-instance_attributes"/>
    <operations>
      <op id="dummy-monitor-interval-60s" interval="60s" name="monitor"/>
    </operations>
  </primitive>
  <meta_attributes id="dummy-master-meta_attributes">
    <nvpair id="dummy-master-meta_attributes-a" name="a" value="b"/>
    <nvpair id="dummy-master-meta_attributes-b" name="b" value="c"/>
  </meta_attributes>
</master>
...


Expected results:
[vm-rhel72-1 ~] $ pcs cluster cib
...
<master id="dummy-master">
  <primitive class="ocf" id="dummy" provider="heartbeat" type="Dummy">
    <instance_attributes id="dummy-instance_attributes"/>
    <operations>
      <op id="dummy-monitor-interval-60s" interval="60s" name="monitor"/>
    </operations>
    <meta_attributes id="dummy-meta_attributes">
      <nvpair id="dummy-master-meta_attributes-a" name="a" value="b"/>
    </meta_attributes>
  </primitive>
  <meta_attributes id="dummy-master-meta_attributes">
    <nvpair id="dummy-master-meta_attributes-b" name="b" value="c"/>
  </meta_attributes>
</master>
...
Comment 3 Ivan Devat 2016-11-07 07:19:40 UTC 
> 2.1) flag --master affects the meta attributes even if pcs reports that flag --master is ignored.

[vm-rhel72-1 ~] $ pcs resource create R1 ocf:heartbeat:Dummy meta a=b --clone --no-default-ops
[vm-rhel72-1 ~] $ pcs resource create R2 ocf:heartbeat:Dummy meta a=b --clone --no-default-ops --master
Warning: --master ignored when creating a clone

In cib there is:
      <clone id="R1-clone">
        <primitive class="ocf" id="R1" provider="heartbeat" type="Dummy">
          <instance_attributes id="R1-instance_attributes"/>
          <meta_attributes id="R1-meta_attributes">
            <nvpair id="R1-meta_attributes-a" name="a" value="b"/>
          </meta_attributes>
          <operations>
            <op id="R1-monitor-interval-60s" interval="60s" name="monitor"/>
          </operations>
        </primitive>
        <meta_attributes id="R1-clone-meta_attributes"/>
      </clone>
      <clone id="R2-clone">
        <primitive class="ocf" id="R2" provider="heartbeat" type="Dummy">
          <instance_attributes id="R2-instance_attributes"/>
          <operations>
            <op id="R2-monitor-interval-60s" interval="60s" name="monitor"/>
          </operations>
        </primitive>
        <meta_attributes id="R2-clone-meta_attributes"/>
      </clone>

Note that there is the meta option named "a" in R1-clone whilst in R2-clone there is not such meta option.
Comment 4 Ivan Devat 2016-11-08 09:49:25 UTC 
> 2.2) flag --master invalidate flag --disable even if pcs reports that flag --master is ignored.

[vm-rhel72-1 ~] $ pcs resource create R1 ocf:heartbeat:Dummy --clone --disable
[vm-rhel72-1 ~] $ pcs resource create R2 ocf:heartbeat:Dummy --clone --disable --master
Warning: --master ignored when creating a clone
In cib there is:
      <clone id="R1-clone">                                                     
        <primitive class="ocf" id="R1" provider="heartbeat" type="Dummy">       
          <instance_attributes id="R1-instance_attributes"/>                    
          <meta_attributes id="R1-meta_attributes">                             
            <nvpair id="R1-meta_attributes-target-role" name="target-role" value="Stopped"/>
          </meta_attributes>                                                    
          <operations>                                                          
            <op id="R1-start-interval-0s" interval="0s" name="start" timeout="20"/>                                                                                                                                                                                        
            <op id="R1-stop-interval-0s" interval="0s" name="stop" timeout="20"/>
            <op id="R1-monitor-interval-10" interval="10" name="monitor" timeout="20"/>
          </operations>                                                         
        </primitive>                                                            
        <meta_attributes id="R1-clone-meta_attributes"/>                        
      </clone>                                                                  
      <clone id="R2-clone">                                                     
        <primitive class="ocf" id="R2" provider="heartbeat" type="Dummy">       
          <instance_attributes id="R2-instance_attributes"/>                    
          <operations>                                                          
            <op id="R2-start-interval-0s" interval="0s" name="start" timeout="20"/>
            <op id="R2-stop-interval-0s" interval="0s" name="stop" timeout="20"/>
            <op id="R2-monitor-interval-10" interval="10" name="monitor" timeout="20"/>
          </operations>                                                         
        </primitive>                                                            
        <meta_attributes id="R2-clone-meta_attributes"/>                        
      </clone>

Note that with R2 there is no meta-attribute named target-role.
Comment 6 Ivan Devat 2017-01-31 14:22:20 UTC 
Created attachment 1246265 [details]
proposed fix

Tests are in the patch.
Comment 7 Ivan Devat 2017-02-20 08:01:54 UTC 
After Fix:

[vm-rhel72-1 ~] $ rpm -q pcs
pcs-0.9.156-1.el7.x86_64

> 1.a

[vm-rhel72-1 ~] $ pcs resource create R ocf:heartbeat:Dummy state=a --master is-managed=false
[vm-rhel72-1 ~] $ pcs cluster cib|grep '\(id="R-instance_attributes"\|id="R-master-meta_attributes"\)' -A 2
          <instance_attributes id="R-instance_attributes">
            <nvpair id="R-instance_attributes-state" name="state" value="a"/>
          </instance_attributes>
--
        <meta_attributes id="R-master-meta_attributes">
          <nvpair id="R-master-meta_attributes-is-managed" name="is-managed" value="false"/>
        </meta_attributes>

> 1.b

[vm-rhel72-1 ~] $ pcs resource create R ocf:heartbeat:Dummy state=a op monitor interval=10s --master fake=b --no-default-ops
[vm-rhel72-1 ~] $ pcs cluster cib|grep 'id="\(R-monitor-interval-10s\|R-master-meta_attributes-fake\)"'
            <op id="R-monitor-interval-10s" interval="10s" name="monitor"/>
          <nvpair id="R-master-meta_attributes-fake" name="fake" value="b"/>

> 2

[vm-rhel72-1 ~] $ pcs resource create R ocf:heartbeat:Dummy meta a=b --master b=c
[vm-rhel72-1 ~] $ pcs cluster cib|grep 'id="\(R-meta_attributes\|R-master-meta_attributes\)"' -A2
          <meta_attributes id="R-meta_attributes">
            <nvpair id="R-meta_attributes-a" name="a" value="b"/>
          </meta_attributes>
--
        <meta_attributes id="R-master-meta_attributes">
          <nvpair id="R-master-meta_attributes-b" name="b" value="c"/>
        </meta_attributes>

> 2.1-2 - Use `--master`. Or reject it. But do not ignore it.

[vm-rhel72-1 ~] $ pcs resource create R ocf:heartbeat:Dummy meta a=b --clone --master
Error: you cannot specify both clone and master

[vm-rhel72-1 ~] $ pcs resource create R ocf:heartbeat:Dummy --clone --disable --master
Error: you cannot specify both clone and master
Comment 15 errata-xmlrpc 2017-08-01 18:22:57 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-2017:1958
Comment 16 Steven J. Levine 2018-03-12 16:57:22 UTC 
Ivan:

This update/fix was never published in the release notes for 7.4.  I have now updated the document on the Portal to account for this change and I think we should also add this to the 7.4 release notes.  I have written up a description in the doc text field.

Could you review what I have here?  Thanks.

Steven
Comment 17 Ondrej Faměra 2018-03-13 02:34:55 UTC 
Steven, doc text looks good to me. Keeping the needinfo for Ivan to check this.

Ivan: This came as documentation improvement request from bz1549446 where new syntax caused some confusion.
Comment 18 Ivan Devat 2018-03-13 09:02:07 UTC 
Hi Steven,

it looks fine. Just maybe a little refinement. I would modify the sentence:

> Previously, when a "pcs" resource creation command included the "--master" flag, all following options were interpreted as master "meta" attributes.
  
to something like this:

> Previously, when a "pcs" resource creation command included the "--master" flag, all options after keyword "meta" were interpreted as master "meta" attributes. *)

Otherwise it looks good to me.

*) Moreover, all options after the flag "--master" were interpreted as options for the section that was listed before the flag "--master" (e.g. primitive resource options, operation options).
But I'm not sure if it is worth to mention it.
Note You need to log in before you can comment on or make changes to this bug.