Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1898743

Summary: validations for dns and tls-everywhere-pre-deployment failing even when they're not used in the deployment
Product: Red Hat OpenStack Reporter: David Hill <dhill>
Component: documentationAssignee: Roger Heslop <rheslop>
Status: CLOSED CURRENTRELEASE QA Contact: RHOS Documentation Team <rhos-docs>
Severity: low Docs Contact:
Priority: medium    
Version: 16.1 (Train)CC: alee, amcleod, cjeanner, dpeacock, dwilde, gchamoul, gfidente, jjoyce, johfulto, jschluet, jslagle, rheslop, slinaber, tvignaud
Target Milestone: z8Keywords: Reopened, Triaged
Target Release: 16.1 (Train on RHEL 8.2)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-04-19 18:56:07 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 David Hill 2020-11-18 00:58:20 UTC
With small deployment, some validations are always failing.  In this case, dns , tls-everywhere-pre-deployment and ceph-pg are failing but none of them are used in the actual deployment:

(undercloud) [stack@undercloud-0-rhosp16 ~]$ openstack tripleo validator show history
+--------------------------------------+-------------------------------------+--------+-----------------------------+-------------+
| UUID                                 | Validations                         | Status | Execution at                | Duration    |
+--------------------------------------+-------------------------------------+--------+-----------------------------+-------------+
| cb96ffdd-8ffb-49b8-af77-881c1b0635e5 | 512e                                | PASSED | 2020-11-14T19:05:48.479781Z | 0:00:01.817 |
| 5ca1de3c-844c-4976-b70d-d854c533862d | dns                                 | FAILED | 2020-11-14T19:05:51.543026Z | 0:00:20.715 |
| 35676d70-0ca6-4248-b393-81fa5ddcc459 | service-status                      | PASSED | 2020-11-14T19:06:13.628661Z | 0:00:16.920 |
| 9058138d-5c9f-42c8-8273-d8d7b87176a3 | validate-selinux                    | PASSED | 2020-11-14T19:06:32.137655Z | 0:00:04.473 |
| 0179fd07-8893-475d-941a-5a3b98d99108 | ceilometerdb-size                   | PASSED | 2020-11-14T19:06:37.918709Z | 0:00:01.733 |
| e6854c8d-7929-4aa9-a7d3-fbe342907276 | ceph-ansible-installed              | PASSED | 2020-11-14T19:06:41.038911Z | 0:00:07.020 |
| 1ee1f27c-38ae-4596-9716-b14972e1be2e | tls-everywhere-pre-deployment       | FAILED | 2020-11-14T19:06:49.313886Z | 0:00:01.768 |
| 8d102809-a27a-4673-abab-4a6c83286e00 | ceph-dependencies-installed         | PASSED | 2020-11-14T19:06:52.315218Z | 0:00:13.521 |
| 018eed2f-e2a6-4c54-9999-3387c4f1738d | ceph-pg                             | FAILED | 2020-11-14T19:07:07.348151Z | 0:00:00.391 |
| fab0142d-fbe2-4ff8-b912-3d01a06eaa8c | collect-flavors-and-verify-profiles | FAILED | 2020-11-14T19:07:09.028188Z | 0:00:03.161 |
| 0b00d9b1-45f3-42d8-8e32-4722cc6dad4d | default-node-count                  | PASSED | 2020-11-14T19:07:13.495834Z | 0:00:05.705 |
| 16fcd5bc-80ee-42e3-90af-e0bd60cf37e8 | dhcp-provisioning                   | PASSED | 2020-11-14T19:07:20.416478Z | 0:00:06.842 |
| afecaa98-c7b0-488d-a711-7e8033acf5dc | undercloud-debug                    | PASSED | 2020-11-14T19:07:28.564627Z | 0:00:01.753 |
| aac6ab93-852d-4bed-83ee-1fc3ab57ae2e | ironic-boot-configuration           | PASSED | 2020-11-14T19:07:31.610433Z | 0:00:01.851 |
| a8e55be5-b087-4323-8dba-baaec64b3a88 | network-environment                 | PASSED | 2020-11-14T19:07:34.748073Z | 0:00:19.114 |
| 429fa314-2e3e-48d2-a8ab-1b20cc81ad6c | node-disks                          | PASSED | 2020-11-14T19:07:55.518984Z | 0:00:05.196 |
| 10e181e8-3db4-449a-a8e6-2786e8bf8fd5 | undercloud-heat-purge-deleted       | PASSED | 2020-11-14T19:08:02.140810Z | 0:00:02.387 |
| 7ade26f0-835b-4eff-9e4a-96125c3199f3 | switch-vlans                        | PASSED | 2020-11-14T19:08:05.830860Z | 0:00:20.115 |
| d9618e00-b449-45cf-b6f0-710db10c090f | undercloud-process-count            | PASSED | 2020-11-14T19:08:27.644715Z | 0:00:11.810 |
+--------------------------------------+-------------------------------------+--------+-----------------------------+-------------+


Version-Release number of selected component (if applicable):
Latest

How reproducible:
Always

Steps to Reproduce:
1.  Deploy a basic overcloud with 3 controllers, 2 computes
2.
3.

Actual results:
pre-deployment group consistently fails on some validations

Expected results:
no failures

Additional info:

Comment 2 John Fulton 2020-11-23 16:47:04 UTC

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

Comment 3 John Fulton 2020-11-23 16:54:52 UTC
The bug was opened because the following validations are failing:

 tls-everywhere-pre-deployment 
 dns
 ceph-pg

The ceph-pg validation issue is addressed by bz 1889159. 

However, I'm re-opening this for the first two failing validations tls-everywhere-pre-deployment and dns. DFG:DF will need to comment on those.

Comment 4 Cédric Jeanneret 2020-11-25 10:54:54 UTC
This BZ was a copy of another one, in order to not get 3 errors in the same BZ. TLS-E is for Security, and the DNS for... errr.. no idea - but I had a look in it already.

Regarding "running validation based on active services": how are we supposed to know what services are active or not? Would love doing a smart filtering, but maybe the ceph related validations could find on their own and gracefully exit if no ceph is configured?

Cheers,

C.

Comment 7 Ade Lee 2022-01-07 19:40:59 UTC
After discussion with the Validations folks, it was determined to change this to a documentation bug.

The main problem is that it is impossible to tell what the intent of the deployer is.  For example,
when the deployer is trying to run a pre-deploy validation, we have no idea whether the deployer plans to deploy
with tls-everywhere or not.  If they do not, then tests to check if the undercloud is an ipa client and has the
right credentials will fail.  If they do, then they need to run the tests to make sure everything is set correctly
and fail if it is not.

Fortunately, there is the ability for the deployer to select tests to be skipped - either on the command line
or in a config file.  The deployer should understand what tests they are running and choose which tests to skip.
This applies not just to tls-e tests but to other optional deployment options too.

So, there is no code fix here - but rather a task to look at the documentation and make sure things are clearly explained.