initial addition of pre-installation verification scripts

[stratus-ss]

What does this PR do?

This pull request adds 2 class files and one executable script which test for the following

• tests to ensure ssh keys exist from ansible host to all OSE hosts in the ansible host file
• checks to see if SELinux is enabled
• checks forward and reverse dns lookups
• checks to see if the docker files have been modified from their defaults
• checks to see if docker is enabled and running
• checks to see if the host is properly subscribed
• ensures the correct repos are available
• checks to see that all of the OSE required packages are installed
• checks to see if there are updates available in general for the system

  How should this be manually tested?

It has standard python usage help

[root@lb00 OSE_Setup]# time ./validate_ose.py -h
Usage: validate_ose.py [options]

Options:
  -h, --help            show this help message and exit
  --ansible-host-file=ANSIBLE_HOST_FILE
                        Specify location of ansible hostfile
  --show-sha-sums=SHOW_SHA_SUMS
                        Toggle whether or not to show the sha sum of fileson
                        remote host

This script is an audit only and will not do any changes on its own. It can be run like so:

./validate_ose.py --ansible-host-file ~/working_ansible --show-sha-sums yes

show_shaw_sums is optional and can be omitted. ansible-host-file is required and the script will terminate if no host file is specified.

The script uses the following colourization schemes for more readable output.

HEADER = '\033[95m'   # Purple
OKBLUE = '\033[94m'   # Blue
OKGREEN = '\033[92m'  # Green
WARNING = '\033[93m'  # Yellow
FAIL = '\033[91m'     # Red
ENDC = '\033[0m'      # Ends special colourization
BOLD = '\033[1m'      # makes text bold
UNDERLINE = '\033[4m' # currently not implemented
HIGHLIGHT = '\033[96m'# currently not implemented

The script expects to parse an ansible host file or a text file with a list of fqdns

Sample output:

Is there a relevant Issue open for this?

Open trello card: https://trello.com/c/ZzI1p8bN

Who would you like to review this?

/cc @etsauer @JaredBurck

[detiber]

A few comments:

• Docker shouldn't be a pre-requisite for running openshift-ansible, it should be pulled in as necessary.
• What is the purpose of warning if the docker-storage-setup file has been modified? We currently tell users to do this as a pre-requisite step in the installer docs.
• It would be really nice to see this implemented as a set of Ansible modules rather than a separate script. In general, I'm thinking a local pre-requisites module and a remote pre-requisites module. This would be something that we could then include in the installer proper, you wouldn't be able to colorize the output as much, but you would still be able to output warnings and errors. A callback plugin would also allow for better output to be provided using a wrapper script as well.

[stratus-ss]

@detiber

RE: Docker, our docs have it as a pre-requisite for running the advanced installation. Therefore it went in to the script

RE: Warning of a file change, the purpose of this is that we cannot know whether the file is correct, however it is important to know when it isn't modified. I chose the yellow colour to indicate that we recognize a change has been made but don't know if it is correct, therefore I didn't feel that green was necessarily the most appropriate colour

RE: ansible. We discussed this a few times during the CASL calls on Fridays with @etsauer @oybed and a few others. The problem as it stood right now, is that ansible isn't great making audit scripts... it wants to take action instead of inform. For the time being its meant to be run as an audit and not a failure condition necessarily.

I spent several days in the Red Hat's ansible slack channel getting help but it just turned out that really ansible wasn't the tool (yet) for what I was trying to achieve. I am willing to admit that this may be a lack of knowledge on my part with how ansible works. I felt it was more appropriate to get some tooling around verification first and then worry about making them an anisble module if that is possible in the future

[detiber]

RE: ansible. We discussed this a few times during the CASL calls on Fridays with @etsauer @oybed and a few others. The problem as it stood right now, is that ansible isn't great making audit scripts... it wants to take action instead of inform. For the time being its meant to be run as an audit and not a failure condition necessarily.

I spent several days in the Red Hat's ansible slack channel getting help but it just turned out that really ansible wasn't the tool (yet) for what I was trying to achieve. I am willing to admit that this may be a lack of knowledge on my part with how ansible works. I felt it was more appropriate to get some tooling around verification first and then worry about making them an anisble module if that is possible in the future

Understood, and in general, I would agree that ansible isn't a great audit tool, it just makes it a bit easier to integrate with the current tooling that we have for the installer wrapper and product integrations.

With a bit of work (and that work can fall on my team), I think we can easily extend what is there to allow it to be run both as an ansible module and as a standalone python script to be able to accomplish both tasks.

[etsauer]

@stratus-ss couple changes to the repo since this was submitted. now we have a permanent space for this stuff. Could you make the following structure/name changes please?

• move directory and scripts into the /solutions folder
• rename your directory to validation (/solutions/validation)
• rename the main script to validate-pre-install.py
• i think maybe the helper scripts should go into a sub folder? /solutions/validation/lib, /solutions/validation/helpers/? @sabre1041 @oybed thoughts here?

Finally, on the Docker stuff, as @detiber says, Docker isn't a hard pre-req for the install to succeed, but it could once again indicate that they forgot to do certain "advanced" configurations like storage. I would change the docker portion to be a warning like the docker-storage-setup warning. Say something like, "the installer will do this for you, but you won't have an opportunity to do any advanced configs".

Sound good?