Description of problem: 'pcs resource config <resource>' does not show 'op monitor timeout' when only 'op monitor interval' is specified Version-Release number of selected component (if applicable): pcs-0.10.4-6.el8.x86_64 pacemaker-2.0.3-5.el8.x86_64 How reproducible: Always Steps to Reproduce: create a resource with only 'op monitor interval' specified. # pcs resource create test1 ocf:pacemaker:Dummy op monitor interval=10 Actual results: # pcs resource config test1 Resource: test1 (class=ocf provider=pacemaker type=Dummy) Operations: migrate_from interval=0s timeout=20s (test1-migrate_from-interval-0s) migrate_to interval=0s timeout=20s (test1-migrate_to-interval-0s) monitor interval=10 (test1-monitor-interval-10) <===== timeout value is not displayed reload interval=0s timeout=20s (test1-reload-interval-0s) start interval=0s timeout=20s (test1-start-interval-0s) stop interval=0s timeout=20s (test1-stop-interval-0s) you can not check timeout value. with 'pcs resource config <resource>' Expected results: 'pcs resource config <resource>' shows timeout value like other conditions. When 'op monitor timeout' value is specified, you can see the interval and timeout settings. # pcs resource create test2 ocf:pacemaker:Dummy op monitor timeout=10 # pcs resource config test2 Resource: test2 (class=ocf provider=pacemaker type=Dummy) Operations: migrate_from interval=0s timeout=20s (test2-migrate_from-interval-0s) migrate_to interval=0s timeout=20s (test2-migrate_to-interval-0s) monitor interval=60s timeout=10 (test2-monitor-interval-60s) <=========== reload interval=0s timeout=20s (test2-reload-interval-0s) start interval=0s timeout=20s (test2-start-interval-0s) stop interval=0s timeout=20s (test2-stop-interval-0s) When none is specified, you can see the op monitor interval and timeout settings. # pcs resource create test3 ocf:pacemaker:Dummy # pcs resource config test3 Resource: test3 (class=ocf provider=pacemaker type=Dummy) Operations: migrate_from interval=0s timeout=20s (test3-migrate_from-interval-0s) migrate_to interval=0s timeout=20s (test3-migrate_to-interval-0s) monitor interval=10s timeout=20s (test3-monitor-interval-10s) <=========== reload interval=0s timeout=20s (test3-reload-interval-0s) start interval=0s timeout=20s (test3-start-interval-0s) stop interval=0s timeout=20s (test3-stop-interval-0s) Additional info: The customer is confused with the output of 'pcs resource show <resource>' running pacemaker on RHEL7. Considering RHEL7 will step into it's Maintenance Support 2 soon, I wish we can have this issue addressed with RHEL8.
The displaying actually works correctly and as intended. Let me elaborate each case: (In reply to Seunghwan Jung from comment #0) > # pcs resource config test1 > Resource: test1 (class=ocf provider=pacemaker type=Dummy) > Operations: migrate_from interval=0s timeout=20s (test1-migrate_from-interval-0s) > migrate_to interval=0s timeout=20s (test1-migrate_to-interval-0s) > monitor interval=10 (test1-monitor-interval-10) <===== timeout value is not displayed > reload interval=0s timeout=20s (test1-reload-interval-0s) > start interval=0s timeout=20s (test1-start-interval-0s) > stop interval=0s timeout=20s (test1-stop-interval-0s) > > you can not check timeout value. with 'pcs resource config <resource>' Since no timeout value has been specified, no timeout value is present in the CIB, and therefore it is not displayed. Similarly, ocf:pacemaker:Dummy's fake, state, passwd and other attributes are not displayed either. > When 'op monitor timeout' value is specified, you can see the interval and timeout settings. > > # pcs resource create test2 ocf:pacemaker:Dummy op monitor timeout=10 > # pcs resource config test2 > Resource: test2 (class=ocf provider=pacemaker type=Dummy) > Operations: migrate_from interval=0s timeout=20s (test2-migrate_from-interval-0s) > migrate_to interval=0s timeout=20s (test2-migrate_to-interval-0s) > monitor interval=60s timeout=10 (test2-monitor-interval-60s) <=========== > reload interval=0s timeout=20s (test2-reload-interval-0s) > start interval=0s timeout=20s (test2-start-interval-0s) > stop interval=0s timeout=20s (test2-stop-interval-0s) You cannot have a monitor operation without an interval, so pcs sets one up for you. Timeout has been specified by the user, therefore it is present in the CIB and displayed. > When none is specified, you can see the op monitor interval and timeout settings. > > # pcs resource create test3 ocf:pacemaker:Dummy > # pcs resource config test3 > Resource: test3 (class=ocf provider=pacemaker type=Dummy) > Operations: migrate_from interval=0s timeout=20s (test3-migrate_from-interval-0s) > migrate_to interval=0s timeout=20s (test3-migrate_to-interval-0s) > monitor interval=10s timeout=20s (test3-monitor-interval-10s) <=========== > reload interval=0s timeout=20s (test3-reload-interval-0s) > start interval=0s timeout=20s (test3-start-interval-0s) > stop interval=0s timeout=20s (test3-stop-interval-0s) You cannot have a resource without a monitor operation. If you do not specify any, pcs will take its default configuration from resource agent's metadata and save it in the CIB. So, the issue is not about displaying the configuration. That works correctly, as shown above. The issue is: When an operation timeout is not specified (or possibly any other optional operation attribute), it is not copied from resource agent's metadata to CIB. We need to take a closer look at this to find out if it is a desired behavior or an actual bug. There is also a related bz1707069 explaining how pacemaker works regarding defaulting op attributes. It explains, among other useful info, that pacemaker does not access resource agent's metadata as they are not available to it.
Commands 'pcs * config' are meant to display configuration and not the currently applied values. We would create a new command for displaying applied values. However, actual applied values may come from several places (specific resource, operation defaults, pacemaker defaults...) and they can even depend on current time or other variables (as the operation defaults can be specified using rules, see bz1817547 and bz1862966). There is no point in re-implementing pacemaker's evaluation engine in pcs, the only way to do this is to ask pacemaker. Pacemaker currently provides an interface for this, but it's not ideal, yet. It doesn't take into account pacemaker defaults, for example, which is crucial for the very use case described in comment 0. The RFE on pacemaker side is tracked at https://projects.clusterlabs.org/T684