Bug 1415234

Summary:	pcs should validate names and values of resource meta options
Product:	Red Hat Enterprise Linux 7	Reporter:	Tomas Jelinek <tojeline>
Component:	pcs	Assignee:	Tomas Jelinek <tojeline>
Status:	CLOSED DUPLICATE	QA Contact:	cluster-qe <cluster-qe>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.2	CC:	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:	2021-01-15 07:31:03 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:

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.

Comment 7 Tomas Jelinek 2023-01-24 10:26:10 UTC


*** This bug has been marked as a duplicate of bug 2123570 ***