The installation could completed by running an install without validation using the --skip-check flags.
The following information from the development team explains how the install could complete but the validation was failing:
Issues with NFS validations (when installer is failing after nfs host/folders entered) are connected with registry settings.
Recommended to change the steps and modify registry settings at the end, after all validations passed. Modified steps will be (#5 changed to modify registry settings at the end):
- backup in different folder file dxi.input.vars.yaml, then remove dxi.input.vars.yaml and dxi.resume.yaml in installer folder to reset and re-enter all prompts
- if using openshift private registry and bastion host, you must also add --bastionHost: "./AIOpsManagement.sh --install --bastionHost"
- set "yes" to "create PVs" prompt
- set "use_existing" for registry type, provide registry parameters to pass registry validation
- continue up to masteradmin password prompt. When asked for masteradmin password, stop the installation and edit dxi.input.vars.yml:
- set "registry" to "openshift_private"
- set "registryUrl" to internal registry name, it will be used by pods ( image-registry.openshift-image-registry.svc:5000 )
- set "routeUrl" to external registry route, will be used to push images by installer (according to image tagging in log it is "default-route-openshift-image-registry.apps.ca.fawryhq.corp")
- set "registrySecure" to false
- set "privateRegAuthRequired" to true
- run "./AIOpsManagement.sh --install --bastionHost" to resume installation and fill remaining prompts
One more issue observed will also affect NFS validations and haveged daemonset. For cluster-admin type installation in openshift we need additional SCC for service account "default" to run root (runAsUser: 0) pods from daemonsets:
- oc adm policy add-scc-to-user privileged -z default
NFS validation daemonset and haveged daemonset are using service account default. Without this additional permission we can create a daemonset object, but it will be unable to run pods as root. In events (oc get event) there will be messages like:
79s Warning FailedCreate daemonset/write-pod Error creating: pods "write-pod-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.runAsUser: Invalid value: 0: must be in the ranges: [1010, 1010] spec.containers[0].securityContext.runAsUser: Invalid value: 0: must be in the ranges: [1000600000, 1000609999]]