Bug 1230919
Summary: | [RFE] help people utilizing pcs in scripts by exposing "capabilities" | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Jan Pokorný [poki] <jpokorny> | ||||
Component: | pcs | Assignee: | Tomas Jelinek <tojeline> | ||||
Status: | CLOSED ERRATA | QA Contact: | cluster-qe <cluster-qe> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.2 | CC: | cfeist, cluster-maint, idevat, royoung, rsteiger, tojeline | ||||
Target Milestone: | rc | Keywords: | FutureFeature | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | pcs-0.9.161-1.el7 | Doc Type: | Enhancement | ||||
Doc Text: |
Feature:
Provide a list of pcs and pcsd capabilities.
Reason:
Processes running pcs or connecting to pcsd need to be able to find out which capabilities are provided by pcs/pcsd so they can make decisions based on that.
Result:
Pcs provides a list of capabilities on command line, pcsd provides the list in cluster status and node status json.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-04-10 15:37:49 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
Jan Pokorný [poki]
2015-06-11 18:57:20 UTC
FWIW, Pacemaker prefers "feature set" label for what I likely meant with "capabilities". For demonstration: # systemctl --version > systemd 219 > +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN # pacemakerd -F > Pacemaker 1.1.12 (Build: a9c8177) > Supporting v3.0.9: generated-manpages agent-manpages ncurses libqb-logging libqb-ipc upstart systemd nagios corosync-native atomic-attrd acls Another example: http://www.open-zfs.org/wiki/Feature_Flags As you've been unable to come up with anything to fill this gap for the last year, I resorted to tracking the features/extras I care about on my own in clufter: https://pagure.io/clufter/blob/d46cb340257664289d9af30e9a0a39b5cbf988b9/f/facts.py#_256 As pcs already depends on clufter, I would suggest not to duplicate the effort and keep a single place tracking such knowledge. I'll happily accept the patches extending such knowledge or adding convenient helpers to be called from pcs. It is a good idea to put the list of capabilities to a separate plain-text file (or use JSON to store structures if needed) so both pcs and pcsd as well as others (like clufter) can easily read it. We are not going to implement any "dry run" option in scope of this bz. There is already a separate bz which requests this feature: bz1330774 Summary (from a parallel discussion) of my vision as far as CLI usability is concerned: - for the purpose of suitable targeting the destination system and its standard version of pcs in clufter generated sequences of pcs commands, I had no choice but to start tracking some relevant "capabilities" directly in clufter: https://pagure.io/clufter/blob/ddf7628385105e3bef0f4e44f85f8234fcf65195/f/facts.py#_323 so that is rather non-systemic blueprint of what I'd be interested in querying dynamically - my idea about CLI interface for that: $ pcs system can node-maintenance > +node-maintenance $ echo $? > 0 $ pcs system can utilization node-maintenance > -utilization > +node-maintenance $ echo $? > 1 $ pcs system can rainbow unicorns > -rainbow > -unicorns $ echo $? > 2 $ pcs system can > [list of all +capabilities] $ echo $? > 0 I.e., return code is a sum of command-passed identifiers designating capabilities in question that are not recognized/supported. re [comment 11]: Thinking about that and considering [bug 1210833], "system" namespace is perhaps too good to be dedicated to local pcs knowledge, so it might be we worth to use still naturally flowing: pcs itself can ... Another example, this time from DSL world: https://sourceware.org/binutils/docs/ld/Miscellaneous-Commands.html > LD_FEATURE(string) Created attachment 1340655 [details]
proposed fix
Test:
pcs:
* 'pcs --version --full' displays the list of capabilities
pcsd:
* Similar list of capabilities is present in cluster status json provided by pcsd ("pcsd_capabilities").
* Pcsd WUI reacts to capabilities (not)present in the capabilities list. It is sufficient for a capability to be present in either of "available_features" (the old deprecated list) or "pcsd_capabilities" (the new list).
See also how git deals with the extensions in its protocol (and how well it's documented, for that matter): https://github.com/git/git/blob/master/Documentation/technical/protocol-capabilities.txt After Fix: [ant ~] $ rpm -q pcs pcs-0.9.161-1.el7.x86_64 [ant ~] $ pcs --version --full 0.9.161 booth cluster.config.backup-local cluster.config.export.to-pcs-commands cluster.config.import-cman... Similar list of capabilities is present in cluster status json provided by pcsd (key is "pcsd_capabilities"). Owing to a shaky history with "pcs cluster setup" wrt. whether encryption is enabled or disabled by default, I'd also add something like "corosync.setup.default_encrypted". It should be expressly noted that it doesn't apply to CMAN. Related to that: 1. cannot any issue arise from combining non/encrypting-by-default pcs(d) peers in the cluster? 2. does "corosync" apply to both flatiron/CMAN and needle equally? otherwise, there should be more systemic branching, IMHO re [comment 19]: I mean: s/corosync.setup.default_encrypted/corosync.setup.default_nonencrypted/ (In reply to Jan Pokorný from comment #19) > Owing to a shaky history with "pcs cluster setup" wrt. whether > encryption is enabled or disabled by default, I'd also add > something like "corosync.setup.default_encrypted". Good point. If this gets changed again, we will do it. For now I think it does not matter that much, because previous pcs versions did not have the capabilities list. > It should be expressly noted that it doesn't apply to CMAN. > > Related to that: > > 1. cannot any issue arise from combining non/encrypting-by-default > pcs(d) peers in the cluster? Only the pcs instance where the setup command is run matters. > > 2. does "corosync" apply to both flatiron/CMAN and needle equally? > otherwise, there should be more systemic branching, IMHO Yes and no. RHEL6 qdisk is not supported. Configuring quorum options (lms, atb, etc.) is not supported by corosync 1.x. We are not focusing CMAN/corosync 1.x anymore. Thanks for the answers. Regarding 1., so I understand it that some general file/content distribution mechanism present for long already is used, hence any reasonably expectable combination of pcs versions will work correctly when encryption requested as long as the triggering pcs version supports that. Correct? Btw. while it's a bit too late for clufter to start emitting commands that would be universal based on run-time "capabilities" feedback (and such convoluted conditionalizing in "pcs commands output" would also be unnecessarily ugly), the whole facility is going to support feature sketched in <https://pagure.io/clufter/issue/2>. (happy end :) (In reply to Jan Pokorný from comment #22) > Thanks for the answers. Regarding 1., so I understand it that some > general file/content distribution mechanism present for long already > is used, hence any reasonably expectable combination of pcs versions > will work correctly when encryption requested as long as the > triggering pcs version supports that. Correct? Yes. 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:0866 |