Debugging issues with the fas2discourse Operator

Resources

Workload

The operator runs in the namespace: fas2discourse-operator on both the staging and production openshift clusters.

There is a single pod running. First port of call should be to examine the logs of this pod.

By default, the verbocity of logs are set low. To increase them to debug level add the following annotation to the Fas2DiscourseConfig object in the fas2discourse-operator namespace:

apiVersion: fas2discourse.apps.fedoraproject.org/v1alpha1
kind: Fas2discourseConfig
metadata:
  annotations:
    ansible.sdk.operatorframework.io/verbosity: '5'

This will enable full output from logging, which may aid in debugging.

The following task list is contained inside the operator. This list is repeated in the reconcile loop which is currently set to run every 20 minutes. Reconcile loop can be adjusted in watches.yaml file.

# tasks file for Fas2discourseConfig

- include_tasks: retrieve_openshift_secrets.yml  # Retrieves the secrets such as discourse api key etc and populates variable which feeds into the later tasks
- include_tasks: kerberos_auth.yml               # Authenticate to fasjson via keytab
- include_tasks: retrieve_discourse_groups.yml   # Contact Discourse API, retrieve the list of groups, and retrieve the list of users in each group
- include_tasks: retrieve_ipa_groups.yml         # Contact fasjson, using the Discourse group list, retrieve the membership of each group in IPA
- include_tasks: sync_group_membership.yml       # Using set functions, discover who is not in Discourse group but is in IPA group: add them. Who is in Discourse group but not in IPA group: remove them.

The results of each call in the workflow is outputted in the log. If any task fails the entire loop stops and retries.

Contributors

Simple guide to troubleshooting in codeready containers.

  • Make the change

  • Tag and create new image and push to registry

    Open Makefile and bump up the version make podman push quay.io/fedora/fas2discourse-operator:<VERSION>

    In case you don’t have the permissions to push to the repositories in the fedora namespace, push to your own namespace in quay.io and pull the image into crc from there.

  • Start crc and login

    crc start oc login -u kubeadmin https://api.crc.testing:6443

  • Deploy controller to the k8s cluster make deploy

  • Remove the deployment and deploy again

    oc get deployments oc delete <deployment NAME> make deploy

  • Check if in correct project

    oc project fas2discourse-operator

  • Apply Fas2DiscourseConfig custom resource

    oc apply -f config/samples/_v1alpha1_fas2discourseconfig.yaml

  • Check t/he logs:

    oc get pods oc logs -f <pod NAME>

Local testing or developing

The guide above will work only when running in the cluster. For local testing, it is necessary to create a secret. For that you have to create a [Discourse API key] (https://meta.discourse.org/t/create-and-configure-an-api-key/230124) (probably in staging Discourse instance) and a [keytab file] (https://pagure.io/fedora-infra/howtos/blob/main/f/create_keytab.md) for kinit.

Create a secret

With command oc create secret generic. Let’s name it fas2discourse-operator-discourse-apikey-secret.

FAS2DISCOURSE_API_KEY=<insert your Discourse API key> DISCOURSE_HOST=https://askfedora.staged-by-discourse.com/ KEYTAB_NAME=<insert name on the keytab file> KEYTAB_PATH=<insert path to the keytab file>

For example: oc create secret generic fas2discourse-operator-discourse-apikey-secret -n fas2discourse-operator --from-literal fas2discourse-discourse-apikey=$FAS2DISCOURSE_API_KEY --from-literal discourse-host="$DISCOURSE_HOST"

oc create secret generic fas2discourse-operator-keytab-secret --from-file=$KEYTAB_NAME="$KEYTAB_PATH"

To confirm the secret was created, run: oc get secrets

Continue with applying the Fas2DiscourseConfig custom resource.

Want to help? Learn how to contribute to Fedora Docs ›