Bug 1378107

Summary: Misbehavior of the flag --master in "pcs resource create" command
Product: Red Hat Enterprise Linux 7 Reporter: Ivan Devat <idevat>
Component: pcsAssignee: Ivan Devat <idevat>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.2CC: cfeist, cluster-maint, idevat, ofamera, omular, rsteiger, slevine, tojeline
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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
 Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 18:22:57 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 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.