Bug 1415234 - pcs should validate names and values of resource meta options
Summary: pcs should validate names and values of resource meta options
Status: NEW
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: 2020-01-01 17:31 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
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.

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