redhat-gpte-devopsautomation/ansible-operator-roles

Ansible Roles to create various OpenShift Applications

Ansible Roles for Ansible Operators

This repository contains roles that can be used to set up various applications on Red Hat OpenShift Container Platform. The primary purpose of these roles is to be used in Operators to be deployed to a cluster.

Available roles:

• PostgreSQL (used by other applications)

• Gogs: Github compatible repository

• Gitea: Github compatible repository

• SonarQube: Code Analysis tool

• Nexus: Artifact Manager, Proxy and Container Registry

ansible-operator-roles's Issues

Ansible Role Failed

While performing these operations
$ ./create_nexus.sh
$ ./create_gitea.sh
$ ./create_sonarqube.sh
$ ./create_gogs.sh

I'm getting this below error.
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ModuleNotFoundError: No module named 'kubernetes'
failed: [localhost] (item=./templates/persistent_volume_claim.j2) => {"ansible_loop_var": "item", "changed": false, "error": "No module named 'kubernetes'", "item": "./templates/persistent_volume_claim.j2", "msg": "Failed to import the required Python library (openshift) on k8s-master's Python /usr/bin/python3. Please read module documentation and install in the appropriate location. If the required library is installed, but Ansible is using the wrong Python interpreter, please consult the documentation on ansible_python_interpreter"}

OS used here: RHEL 7.8

Convert Nexus Bash Setup to Ansible Tasks

I would like to see us convert the bash script to ansible tasks and make the proxies, repos, registries, etc. configurable via variables. This will be especially handy when used as an OpenShift operator. These can be configured in the CR.

Nexus setup task failing...

I'm getting this error when installing Nexus on my OCP 4.6 cluster:

TASK [nexus-ocp : Perform Initial Nexus Configuration] *******************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"reason": "couldn't resolve module/action 'operator_sdk.util.k8s_status'. This often indicates a misspelling, missing collection, or incorrect module path.\n\nThe error appears to be in '/Users/rsoares/dev/ansible/ansible-operator-roles/roles/nexus-ocp/tasks/setup.yml': line 334, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# Report current admin password in Nexus CR status\n- name: Save password in custom resource status\n  ^ here\n"}

Setup of Nexus fails when using self-signed certificates

When using self signed certificates on a cluster calling the "Declare Groovy Script" steps fail.

fatal: [localhost]: FAILED! => {"changed": false, "msg": "Failed to validate the SSL certificate for nexus3-gpte-operators.apps.cluster-minimal.minimal.ocp4.opentlc.com:443. Make sure your managed systems have a valid CA certificate installed. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tls/certs, /usr/share/ca-certificates/cacert.org, /etc/ansible. The exception msg was: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)."}

new_nexus_admin_password is not a secret

If you wish to change the admin password on initial setup, the variable new_nexus_admin_password is defined in the CR (or playbook invocation). Currently when used in the CR, the password is plain text and remains sitting in the CR for anyone with proper permissions to see.

It would be nice if this were a secret or hashed in some way.

Nexus 3.17+ does not default to anonymous access

Starting with Nexus 3.17, the default is no anonymous access. Anonymous access has to be explicitly granted.

We have to figure out how to call the API to do this.

Nexus 3.17+ no longer uses well-known admin password

Starting in Nexus 3.17.0 the admin password is no longer well-known. Instead a random password is generated and place in /nexus-data/admin.password.

We need to read this password from the pod and use it in our initial setup routines.