Bug 1898482 - [RHOSP16.1] Execute Ansible-based validation "prep" before installing the undercloud
Summary: [RHOSP16.1] Execute Ansible-based validation "prep" before installing the und...
Keywords:
Status: CLOSED DUPLICATE of bug 1843960
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 16.1 (Train)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: RHOS Documentation Team
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On: 1892323
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-17 09:48 UTC by Yadnesh Kulkarni
Modified: 2024-03-25 17:06 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-28 06:08:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-1419 0 None None None 2022-08-30 14:44:55 UTC
Red Hat Knowledge Base (Solution) 5590561 0 None None None 2020-11-20 14:55:52 UTC

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


Note You need to log in before you can comment on or make changes to this bug.