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

Bug 1898482

Summary:	[RHOSP16.1] Execute Ansible-based validation "prep" before installing the undercloud
Product:	Red Hat OpenStack	Reporter:	Yadnesh Kulkarni <ykulkarn>
Component:	documentation	Assignee:	RHOS Documentation Team <rhos-docs>
Status:	CLOSED DUPLICATE	QA Contact:	RHOS Documentation Team <rhos-docs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	16.1 (Train)	CC:	cjeanner, dhill, dmacpher, dpeacock, gchamoul, jjoyce, jpodivin, jschluet, mbultel, slinaber, tvignaud
Target Milestone:	---	Keywords:	Documentation, Triaged
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-06-28 06:08:52 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:
Bug Depends On:	1892323
Bug Blocks:

Description Yadnesh Kulkarni 2020-11-17 09:48:15 UTC

Description of problem:

In RHOSP 16.1.1 release, to execute the ansible-based validation "prep", does the undercloud need to be installed first ? 

The doc[1] mentions to run this validation before installing the undercloud
~~~
prep
Validations that check the hardware configuration of the undercloud node. Run these validation before you run the openstack undercloud install command.
~~~

On doing so, it asks to source the stackrc, which gets generated after installing the undercloud
~~~
[stack@nfv-undercloud-0 ~]$ openstack tripleo validator run --group prep
Missing value auth-url required for auth plugin password
~~~

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/director_installation_and_usage/using-the-validation-framework#ansible-based-validations

Version-Release number of selected component (if applicable):
openstack-tripleo-validations-11.3.2-0.20200611115253.08f469d.el8ost.noarch
ansible-2.9.14-1.el8ae.noarch

Comment 1 Cédric Jeanneret 2020-11-18 09:30:46 UTC

Hello Yadnesh,

Short answer: "it's complicated".

Longer: we have a couple of patches that will actually allow running the validations before the undercloud is deployed. Some doc update will be needed in order to show how to do it, especially regarding the inventory (we'll need a static yaml file describing the undercloud node, in the right format).

We wanted to get the missing bit in for 16.1.3, buuut... it will be in for 16.1.4. Your request is a "duplicate" of another one we got about FFU - at some point of the process, no container nor openstack services are running on the undercloud, and there's a need to run validation. It is described here: https://bugzilla.redhat.com/show_bug.cgi?id=1892323, and the related patch here: https://code.engineering.redhat.com/gerrit/#/c/216992/

Once that last bit is in, it will be possible to do the following:
- install tripleoclient (and dependencies)
- run `openstack tripleo validator run --group prep --static-inventory undercloud.yaml'
- proceed to the standard undercloud deploy once we're sure everything is OK

Note: there might be an additional step regarding the log directory, we have to ensure it's present. Not sure if any package manage it yet.

Does it answer your question? Do you agree to mark this BZ as a plain duplicate of the other one I just mentioned?

Cheers,

C.

Comment 2 Yadnesh Kulkarni 2020-11-18 11:42:07 UTC

Hello Cedric,

Thanks heaps for clarifying this. Sure, we can mark this bug as duplicate of the other one.

Comment 3 Cédric Jeanneret 2020-11-18 12:44:32 UTC

Hey Yadnesh,

cool :). In fact I'll keep it as a Doc issues, in order to push an update regarding running prep and other consideration.

Cheers,

C.

Comment 4 Dan Macpherson 2021-03-01 17:44:15 UTC

@cjeanner -- Is the static inventory something we provide, or do customers have to manually create that before running the prep validation?

Comment 5 Cédric Jeanneret 2021-03-02 12:32:27 UTC

Hey Dan,

for now nothing is provided. Not sure about the best way for that, but I'm pretty sure it will end with a doc note with an example of a valid inventory including only the undercloud. Maybe the tripleo-validations package can provide a static inventory as well, meaning the doc will just need to point to it? Not sure about the best solution (though... providing something in the package is probably the best thing, though I'm not 100% sure such an inventory will work on every single UC).

Might be good getting @gchamoul @dpeacock @mbultel @jpodivin views on this specific question.

Cheers,

C.

Comment 6 Jiri Podivin 2021-03-02 16:00:06 UTC

Alternative to a yaml file, or doc note, could be having default inventory (undercloud only) created during runtime, and kept purely as an in mrmory python object.
Package wouldnt nee another file and the important bits would stay under the hood.

Comment 8 Gaël Chamoulaud 2021-03-29 07:26:43 UTC

Hi,

Yes to me we should only provide a documented procedure for that. 

As Cédric mentioned in comment #1:
- install tripleoclient (and dependencies)
- run `openstack tripleo validator run --group prep --static-inventory undercloud.yaml'
- proceed to the standard undercloud deploy once we're sure everything is OK

For information, tripleo-validations is already providing a simple "hosts.sample"[1] file since the beginning the tripleo-validations project.
This inventory sample is including references to the overcloud nodes as well and I am not sure it is still accurate. We will probably need to improve it.

FWITW, this file is already installed by the rpm in /usr/share/ansible/hosts.sample. 

[1] - https://opendev.org/openstack/tripleo-validations/src/branch/master/hosts.sample

Comment 9 Dan Macpherson 2021-06-28 06:08:52 UTC


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

Comment 10 Red Hat Bugzilla 2023-09-15 01:31:17 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days