xtophd / ocp4-workshop Goto Github PK

since host is managed by libguestfs after the install, use an ansible password to configure root pw on node OR simply configure random password and stick with the ssh-keys.

can use the exact same config file as installed on bastion at completion of installation. if cluster is on a nat'd private network, the haproxy on the virthost would be a simple point of ingress.

simple change but could have some impact on user community. will make this change during the openshift 4.8 release cycle

Undetermined underlying cause, but the version of either grub64.efi or shimx64.efi that ships on the RHEL 8.3 DVD iso is broken and causes the UEFI PXE implementation to hang during server provisioning. From the tftpboot log (/var/log/messages), the shimx65.efi appears to load as does the grub65.efi, but there the systems hangs and times out. Following the timeout, the console is left at the grub prompt.

From the tftp server logs, the client never downloads the grub.cfg.

This works with the ISOs for RHEL 8.0,8.1 and 8.2.

Is broken with RHEL 8.3

Preliminary testing with RHEL 8.4 BETA shows it is working again.

RHEL 8.3 deprecated the use of ip=XXX netmask=XXX gateway=XXX in the kernel parms. This is a problem with xtoph_deploy and not this workshop. This workshop ony focuses on deployment of RHCOS, which already uses the new format as documents in the config file master-config.yml

pretty straight forward idea. should the existing credential artifacts be backed up before running openshift-install a second time. this is to prevent the loss of data before someone inadvertently and unknowingly runs the playbooks again.

There exists a variable to alter the matchbox_port in group_vars/all matchbox, BUT the templates still use hard coded values. This needs to be cleaned up and tested.

part of the playbooks finishing process that

• watches the cluster deployment progress,
• checks for nodes ready,
• checks for and approves CSR requests,
• checks for clusteroperator availability,
• etc ...

the timeouts are apparently too short for OCP 4.7.

also note that even previously the timeouts are too short for deployments with very slow download links.

3 major issues to consider:

• if timeouts expire and playbooks exit during the bastion buildout (ie: during downloads), the automated deployment ends in failure
• if timeouts expire and playbooks exit during the wait for "nodes ready", the automated detecting and approval of CSR requests ends and the automated deployment ends, but is manually recoverable
• if timeouts expire while waiting for "clusteroperators available", the playbooks end with a failure but the cluster will continue to deploy until successful (probably).

scripts for generation and deployment of self signed certs are included with matchbox. implement and validate https: support for matchbox.

easy enough to do. will plan to update with openshift 4.8 release cycle

https://access.redhat.com/solutions/4906341

if NFS is enabled, configure persistent storage for the image registry

The format for specifying the version of openshift to deploy recently changed from "X_Y" to "X.Y"

You just need to update your master_config.yml so g_clusterVersion = "X.Y"

example:
g_clusterVersion = "4.6"

the openshift installer should exit if an expired cert is detected.

This would allow for the removal of the "lock" mechanism and simplify iterative deployment attempts.
Would also remove confusion of when to run "unlock". Error messaging is clear and mitigations identified.

installer begins

if openshift installation artifacts exist; then
do not re-run install
else
run install
endif

if install-cert expired; then
error message "Certificate has expired"
hint messages "Run deployer with 'clean' option and try again" step (not yet implemented)
exit
fi

proceed with install

In a lab or POC environment, it might be preferred to only use DHCP to facilitate a PXE based deployment, but configure the cluster with static addressing. Thus we could remove a dependency on the bastion and shutdown the dhcpd server at the completion of the deployment.

create additional playbook to watch for pending certificates and auto approve them