Bug 1415234 - pcs should validate names and values of resource meta options
Summary: pcs should validate names and values of resource meta options
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Tomas Jelinek
QA Contact: cluster-qe@redhat.com
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-20 16:08 UTC by Tomas Jelinek
Modified: 2021-01-15 07:31 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-01-15 07:31:03 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Tomas Jelinek 2017-01-20 16:08:17 UTC
When creating or modifying a resource or stonith, pcs should validate values of meta options when possible. For example clone-max, clone-node-max, master-max, master-node-max options can only have values of 0 or a positive integer.

Comment 2 Tomas Jelinek 2017-06-06 08:40:13 UTC
Pcs should also validate names of meta options. For example setting clone-max on a primitive or remote-node on a clone has no effect. Meta options which have no effect for a given resource type (primitive, group, clone, master, bundle) should only be allowed with --force.

All the validations needs to be done in all commands which are capable of setting meta attributes:
* resource meta
* resource update
* resource create - primitive's meta and possible master's or clone's meta must be checked separately
* resource bundle create
* resource clone
* resource master

Comment 3 Tomas Jelinek 2017-06-08 14:41:48 UTC
resource defaults should be validated as well

Comment 4 Tomas Jelinek 2017-06-08 14:43:35 UTC
Option names are not validated currently and it is possible to set options with any name. This may be a valid use case so we need to carefully decide how to deal with unknown option names.

Comment 6 RHEL Program Management 2021-01-15 07:31:03 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

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