Pre-populated entries in group_vars/all.yml are used as default values, to customize further you need to create a cluster file under the clusters folder. Any updates described below refer to changes made in cluster files (See: example cluster file) unless otherwise specified.

• The helper_vm_ip and helper_vm_port are used to build the bootstrap_ignition_url and the no_proxy values if there is a proxy in the environment.

• The config key and it’s child keys are for cluster settings

• The nodes key is how you define the nodes, this array will get further split by type as set in each node object.

  • If you delete macaddr from the node dictionaries VMware will auto-generate your MAC addresses. If you are using DHCP, defining macaddr will allow you to reserve the specified IP addresses on your DHCP server to ensure the OpenShift nodes always get the same IP address.

• The vm_mods key allows you to specify hotadd and core_per_socket options on the vms. These settings are optional.

• The static_ips key and it’s child keys are used for non-DHCP configurations.

• The network_modifications key Network CIDRs default to sensible ranges. If a conflict is present (these ranges of addresses are assigned elsewhere in the organization), you may select other non-conflicting CIDR ranges by changing "enabled: false" to "enabled: true" and entering the new ranges. The ranges shown in the repository are the ones that are used by default, even if "enabled: false" is left as it is.

  • The machine network is the network on which the VMs are created. Be sure to specify the right machine network if you set enabled: true

• The proxy key and it’s child keys are for configuring cluster-wide proxy settings

• The registry key and it’s child keys are for configuring offline or disconnected registries for clusters in restricted networks

• The ntp key and it’s child keys are for configuring time servers to keep the cluster in sync

Now configure ansible.cfg and staging inventory file based on your environment before picking one of the 5 different install options listed below.

Update the staging inventory file

Update the ansible.cfg based on your needs

    [defaults]
    host_key_checking = False

    [defaults]
    host_key_checking = False
    remote_user = root
    ask_pass = True

    [defaults]
    host_key_checking = False

    [privilege_escalation]
    become_ask_pass = True

    [defaults]
    host_key_checking = False
    remote_user = root
    ask_pass = True

    [privilege_escalation]
    become_ask_pass = True

• If you are re-running the installation playbook make sure to blow away any existing VMs (in ocp4 folder) listed below:

  • bootstrap

  • masters

  • workers

  • rhcos-vmware template (if not using the extra param as shown below)

• If a template by the name rhcos-vmware already exists in vCenter, you want to reuse it and skip the OVA download from Red Hat and upload into vCenter, use the following extra param.

• If you would rather want to clean all folders bin, downloads, install-dir and re-download all the artifacts, append the following to the command you chose in the first step

1. Necessary Linux packages installed for the installation. NOTE: support for Mac client to run this automation has been added but is not guaranteed to be complete

2. SSH key-pair generated, with key ~/.ssh/ocp4 and public key ~/.ssh/ocp4.pub

3. Necessary folders [bin, downloads, downloads/ISOs, install-dir] created

4. OpenShift client, install and .ova binaries downloaded to the downloads folder

5. Unzipped versions of the binaries installed in the bin folder

6. In the install-dir folder:

7. append-bootstrap.ign file with the HTTP URL of the boostrap.ign file

8. master.ign and worker.ign

9. base64 encoded files (append-bootstrap.64, master.64, worker.64) for (append-bootstrap.ign, master.ign, worker.ign) respectively. This step assumes you have base64 installed and in your $PATH

10. The bootstrap.ign is copied over to the web server in the designated location

11. A folder is created in the vCenter under the mentioned datacenter and the template is imported

12. The template file is edited to carry certain default settings and runtime parameters common to all the VMs

13. VMs (bootstrap, master0-2, worker0-2) are generated in the designated folder and (in state of) poweredon

ansible-playbook -i staging -e "cluster=ocp-example" new_worker_isos.yml

$ ansible-playbook -i staging -e 'cluster=mycluster' -e "username=kubeadmin" -e "password=$(cat install-dir/auth/kubeadmin-password)" validateCluster.yml

oc --kubeconfig=$(pwd)/install-dir/auth/kubeconfig get nodes
oc --kubeconfig=$(pwd)/install-dir/auth/kubeconfig co
oc --kubeconfig=$(pwd)/install-dir/auth/kubeconfig get mcp
oc --kubeconfig=$(pwd)/install-dir/auth/kubeconfig get csr

• Code cleanup/refactoring

• More common roles and tasks and less duplication of code

• One playbook to rule them all (using tags?)