Add OSE provision prerequisites

[vvaldez]

What does this PR do?

This PR adds prerequisites.yml which is included and tagged from main.yml. I've included all possible rpms that a master and node may need, disabled iptables, enabled firewalld and check that the hostname matches anssible_fqdn and set it if it does not.

How should this be manually tested?

Run ose-provision.yml and this will be automatically called after the instances are provisioned.

Is there a relevant Issue open for this?

No known issues, though if subscriptions are not working properly in the base image any yum actions will fail.

Who would you like to review this?

/cc @oybed @etsauer @sabre1041

[shah-zobair]

Is it possible to include SeLinux check from this?

[vvaldez]

@shah-zobair Sure, what did you have in mind, forcing enabling SELinux I assume?

[shah-zobair]

@vvaldez : Yes, I faced one similar issue today and had to spend some time on it. By default, SELinux is enabled when any system is installed, but customers may use a template to disable it. So, it is better to check it and enable it at the beginning as the installation will fail if SELinux is disabled.

[etsauer]

@shah-zobair @vvaldez unfortunately if a customer has SELinux disabled, a reboot is required to turn it on, as its now somewhat baked into the kernel. We can check for it and halt the provisioning if we notice it missing, but i don't think this playbook/role should do much more than that.

[etsauer]

@vvaldez I think the prereqs would also include installing docker and setting up storage for it no?

[vvaldez]

@etsauer I have a separate PR for that but was wanting to know if I should just use an include and point to the cicd docker.yml or just copy it straight out?

[etsauer]

@vvaldez I think the best answer would be to move the docker piece out of cicd into it's own role, and refactor cicd. For now let's not worry about the refactor, let's just copy the docker piece into a new role that everyone can use, and inherit that into the prereqs role. Sound good?

@sabre1041 ?

[sabre1041]

@vvaldez there are a number of foundational components as part of the cicd role such as docker. As @etsauer suggested, docker should be reactors into its own role. Be on the lookout for any other refactoring opportunities in that role

[etsauer]

@vvaldez @oybed one other question I have here is about setting the hostname. I believe this should probably be delegated to the DNS role instead, but please correct me if i'm wrong.

[vvaldez]

@etsauer @oybed I would think DNS role would only setup the bind server and add existing host entries, the hostname setting on the masters/nodes themselves should be part of whatever role provisioned them right? If it helps, in my testing the hostname was always already set anyway, so what is included in this PR is only checking the hostname for belt/suspenders approach. As a test I inverted the comparison operator and set the hostname to something obviously different and it worked.

[oybed]

@etsauer I agree with @vvaldez that the DNS role should not be in charge of changing/setting the hostname/FQDNs. Basically, the caller needs to ensure that it's set correctly.

Maybe we'd want to create a new role (a very simple one supposedly) that all it handles is the checking/setting/etc. of the hostname (using the built-in hostname feature of Ansible). I can see that as being somewhat useful for many areas, and it ensures a consistent functionality across multiple playbooks.

[oybed]

In addition to the comments above, please check the "tailor" scripts that we use to create the base image for the "old" tools. We need a similar setup for the ansible based tools as well, basically: 1) Need to have a "tailor" section per OSE version that we will support (right now, that's v3.0 and v3.1, but v3.2 is right around the corner). 2) The above is used to tweak the installation per version as there are "always" some workarounds (temporary or permanent) that doesn't apply to other versions. Since we'll be using a stock base image, and no longer create our own, we'd need these tailoring steps to be part of the prep steps. 3) Need to figure out how to handle reboots. Some of the features / functionality will at times require a base os reboot of the instance(s). How do we handle this? Should we go the route of a "utility host" still to manage the env and allow ansible to run uninterrupted.

Maybe these above are bigger topics that we can discuss during the Friday meeting, but these need to be consider as part of the overall plan for the prep/prerequisites work.

[oybed]

BTW: the tailor scripts can be found here: https://github.com/rhtconsulting/rhc-ose/tree/openshift-enterprise-3/provisioning/openstack

[vvaldez]

@shah-zobair @etsauer Done in the latest commit, here's output if SELinux is disabled:

TASK: [openshift-provision | Verify SELinux is enforcing] ********************* 
failed: [master1-testenv-tdbgPK0Y] => {"failed": true}
msg: SELinux is required for OpenShift and has been detected as 'Permissive'
failed: [node2-testenv-tdbgPK0Y] => {"failed": true}
msg: SELinux is required for OpenShift and has been detected as 'Permissive'
failed: [node1-testenv-tdbgPK0Y] => {"failed": true}
msg: SELinux is required for OpenShift and has been detected as 'Permissive'

[vvaldez]

@oybed Will look at the tailor script thanks. As for the hostname role, should that be something like "common-post"?

[vvaldez]

Addressed comments on this PR and resolved merge conflict.

[etsauer]

@vvaldez a few more comments, then I think we'll be good

[JayKayy]

Whats the status of this PR?

[vvaldez]

@JayKayy I'm at OpenStack Summit so just now catching up. I'll get this updated soon.

[etsauer]

Going to go ahead and merge. It works as is, and we will do cleanup as necessary.