Bug 1415234

Summary: pcs should validate names and values of resource meta options
Product: Red Hat Enterprise Linux 7 Reporter: Tomas Jelinek <tojeline>
Component: pcsAssignee: Tomas Jelinek <tojeline>
Status: NEW --- QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: low    
Version: 7.2CC: cfeist, cluster-maint, idevat, omular, tojeline
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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.