Bug 1395812

Summary:	Defaults in Overcloud and Undercloud shouldn't fail in validations
Product:	Red Hat OpenStack	Reporter:	Ramon Acedo <racedoro>
Component:	openstack-tripleo-validations	Assignee:	Ana Krivokapic <akrivoka>
Status:	CLOSED ERRATA	QA Contact:	Udi Kalifon <ukalifon>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	10.0 (Newton)	CC:	akrivoka, augol, beth.white, gchamoul, jjoyce, jschluet, mputhenp, slinaber, tvignaud
Target Milestone:	Upstream M3	Keywords:	Triaged
Target Release:	13.0 (Queens)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	NeedsAllocation
Fixed In Version:	openstack-tripleo-validations-8.1.1-0.20180119231917.2ff3c79.el7ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-27 13:26:39 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 Ramon Acedo 2016-11-16 18:10:25 UTC

Currently some validations fail in OSP 10 deployments deployed with defaults, for example:

[stack@undercloud-4 validations]$ run-validation /usr/share/openstack-tripleo-validations/validations/controller-ulimits.yaml ~/.ssh/id_rsa overcloud
Task 'Check nofiles limit' failed:
Host: 192.168.3.17
Message: nofiles is set to 1024.  It should be at least 2048 or higher, depending on available resources.


Task 'Check nofiles limit' failed:
Host: 192.168.3.9
Message: nofiles is set to 1024.  It should be at least 2048 or higher, depending on available resources.


Task 'Check nofiles limit' failed:
Host: 192.168.3.13
Message: nofiles is set to 1024.  It should be at least 2048 or higher, depending on available resources.


Failure! The validation failed for the following hosts:
* 192.168.3.13
* 192.168.3.17
* 192.168.3.9

This raises the question of the need to either change the default values that make the validations fail or change the validations themselves to match our defaults to avoid the perception that our defaults don't follow our best practices.

I'm filling this BZ against openstack-tripleo-validations but obviously the changes might need to happen in openstack-tripleo-heat-templates for those defaults that need to be changed in the templates to match our recommendations in the openstack-tripleo-validations.

Comment 1 Mohammed Salih 2017-02-21 08:43:34 UTC

We are having the same kind of issue here with haproxy configuration validation. As per validation, it is supposed to have default timeouts for queue, client and server to be 1 minutes, but a recent change in newton defaults the configuration 2 minutes instead. 

So I believe this time it is the validation that needs to be updated. 

On a related note, I feel the whole point of having these tests, especially those related to having configurations correct is like shooting own foot - having an automated deployment, which is supposed to set recommended configurations and then on the other hand validation process says that those are not good.

Comment 7 Ana Krivokapic 2017-12-13 15:13:43 UTC

I believe there's still work to be done here, we have fixed some instances of the defaults mismatch, but not all.

Comment 8 Beth White 2018-01-23 16:19:43 UTC

Decision made to move this bug to POST as further cases have not been found and that could lead to this becoming an un-closeable bug. As further instances are found in the future, bugs will be opened to address them.

Comment 10 Udi Kalifon 2018-05-22 08:30:48 UTC

This validator now passes, although others still fail with their defaults. Marking as verified: 
openstack-tripleo-heat-templates-8.0.2-22.el7ost.noarch
openstack-tripleo-validations-8.4.1-5.el7ost.noarch

Comment 12 errata-xmlrpc 2018-06-27 13:26:39 UTC

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/RHEA-2018:2086