infra/ansible

Fork 53

Deploy ELNBuildSync to Fedora Infrastructure #3374

Merged

james merged 3 commits from sgallagh/infra-ansible:elnbuildsync-deploy into main

2026-06-09 13:22:42 +00:00

sgallagh commented

2026-05-28 02:27:36 +00:00

Contributor

Adds a new playbook, role and variables for deploying ELNBuildSync to OpenShift in the Fedora Infrastructure.

There are the following secrets that need to be provided to the ansible-private repository (which I do not have access to):

ebs_db_password: The password to the access theelnbuildsync PostgreSQL production database
ebs_stg_db_password: The password to the access theelnbuildsync PostgreSQL production database
ebs_keytab_secret: The base64-encoded keytab for the eln-buildsync FAS user, used to access Koji and Bodhi
ebs_smtp_password: The password for SMTP email-sending
ebs_fedora_messaging_cacert, ebs_fedora_messaging_client_pem, and ebs_fedora_messaging_client_key: certificates for use with fedora-messaging.

I have tested this playbook as best I can with my OpenShift Local cluster, but it's entirely possible that some gremlins remain with the RabbitMQ pieces, which I don't have available to test. Those bits are mostly copied from other OpenShift applications.

Attn: @yselkowitz

Fixes: infra/tickets#13139

Adds a new playbook, role and variables for deploying ELNBuildSync to OpenShift in the Fedora Infrastructure. There are the following secrets that need to be provided to the ansible-private repository (which I do not have access to): * `ebs_db_password`: The password to the access the`elnbuildsync` PostgreSQL production database * `ebs_stg_db_password`: The password to the access the`elnbuildsync` PostgreSQL production database * `ebs_keytab_secret`: The base64-encoded keytab for the `eln-buildsync` FAS user, used to access Koji and Bodhi * `ebs_smtp_password`: The password for SMTP email-sending * `ebs_fedora_messaging_cacert`, `ebs_fedora_messaging_client_pem`, and `ebs_fedora_messaging_client_key`: certificates for use with fedora-messaging. I have tested this playbook as best I can with my OpenShift Local cluster, but it's entirely possible that some gremlins remain with the RabbitMQ pieces, which I don't have available to test. Those bits are mostly copied from other OpenShift applications. Attn: @yselkowitz Fixes: https://forge.fedoraproject.org/infra/tickets/issues/13139

sgallagh added 2 commits

2026-05-28 02:27:36 +00:00

Add ELNBuildSync deployment 2480973203

Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>

rh-pre-commit.version: 2.4.0
rh-pre-commit.check-secrets: ENABLED

Move the ELNBuildSync queue setup

Linter / yamllint (pull_request) Failing after 25s

Details

Linter / ansible-lint (pull_request) Failing after 1m4s

Details

1cc94caa72

Now that ELNBuildSync is being deployed via Ansible, we should keep its
queue setup with the rest of the playbook.

Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>

rh-pre-commit.version: 2.4.0
rh-pre-commit.check-secrets: ENABLED

sgallagh referenced this pull request from infra/tickets

2026-05-28 02:42:47 +00:00

Migrate ELNBuildSync to Fedora Infrastructure OpenShift #13139

sgallagh force-pushed elnbuildsync-deploy from 1cc94caa72

Linter / yamllint (pull_request) Failing after 25s

Details

Linter / ansible-lint (pull_request) Failing after 1m4s

Details

to 26990b71dd

Linter / yamllint (pull_request) Failing after 25s

Details

Linter / ansible-lint (pull_request) Failing after 1m5s

Details

2026-05-28 02:54:13 +00:00

Compare

sgallagh force-pushed elnbuildsync-deploy from 26990b71dd

Linter / yamllint (pull_request) Failing after 25s

Details

Linter / ansible-lint (pull_request) Failing after 1m5s

Details

to 4a787e37b1

Linter / yamllint (pull_request) Successful in 25s

Details

Linter / ansible-lint (pull_request) Successful in 1m10s

Details

AI Code Review / ai-review (pull_request_target) Successful in 42s

Details

2026-05-28 03:02:41 +00:00

Compare

kevin commented

2026-06-01 21:18:01 +00:00

Owner

There shouldn't be a need for a smtp password, you should be able to use our gateway ( bastion.fedoraproject.org ) if you are sending things.

The keytab I think you already have? should we just reuse that?

We can make the db passwords and point to the fedora-messaging files which we should already have.

We should probibly target staging only first, so leave os_control and the prod db out of hosts for now?

There shouldn't be a need for a smtp password, you should be able to use our gateway ( bastion.fedoraproject.org ) if you are sending things. The keytab I think you already have? should we just reuse that? We can make the db passwords and point to the fedora-messaging files which we should already have. We should probibly target staging only first, so leave os_control and the prod db out of hosts for now?

kevin added the

ai-review-please

label

2026-06-01 21:18:09 +00:00

forgejo-actions commented

2026-06-01 21:18:51 +00:00

AI Code Review

Detailed Code Review

The OpenShift and RabbitMQ manifests establish the deployment structure for ELNBuildSync. The architecture correctly follows existing application patterns. However, two critical configuration bugs exist that will cause failures in both deployment and message routing. Certificate filenames in the OpenShift secret mismatch the expected paths in the fedora-messaging TOML configuration, which will result in startup crashes. Furthermore, the TOML configuration hardcodes production URLs and routing keys, meaning any staging deployment will inadvertently connect to and process production message queues.

📂 File Reviews

📄 `roles/openshift-apps/elnbuildsync/templates/fedora-messaging-config.yml.j2` - Creates the fedora-messaging secret including the TOML config and TLS certificates.

Critical [Bug]: The secret defines certificate keys as elnbuildsync.crt and elnbuildsync.key, but the corresponding TOML configuration (vars/apps/elnbuildsync.yml) expects /etc/fedora-messaging/distrobuildsync-eln.key and distrobuildsync-eln.crt. The container will crash on startup due to missing certificate files.
- Suggestion: Update the key names in the Secret manifest to match the paths defined in the TOML configuration.

  distrobuildsync-eln.crt: |-
    {{ ebs_fedora_messaging_client_pem | indent(4) }}
  distrobuildsync-eln.key: |-
    {{ ebs_fedora_messaging_client_key | indent(4) }}

📄 `vars/apps/elnbuildsync.yml` - Defines application variables including the fedora-messaging configuration payload.

Critical [Logic]: The ebs_fedora_messaging_config string hardcodes the production RabbitMQ URL (rabbitmq.fedoraproject.org) and production routing keys (org.fedoraproject.prod...). A deployment to the staging cluster will incorrectly listen to production events.
- Suggestion: Use Ansible variables ({{ env_suffix }} and {{ env_short }}) to dynamically configure the environment endpoints and routing keys in the TOML definition.

  amqp_url = "amqps://fedora:@rabbitmq{{ env_suffix }}.fedoraproject.org/%2Fpubsub"
  ...
  routing_keys = [
      "org.fedoraproject.{{ env_short }}.buildsys.repo.init",
      "org.fedoraproject.{{ env_short }}.buildsys.repo.done",
      "org.fedoraproject.{{ env_short }}.buildsys.tag",
      "org.fedoraproject.{{ env_short }}.buildsys.task.state.change"
      ]

✅ Summary

Overall Assessment: Critical configuration issues were identified regarding certificate filename mismatches and hardcoded production values in the message broker configuration.
Priority Issues:
- Fix certificate filename mismatch between fedora-messaging-config.yml.j2 and the TOML configuration to prevent container crash loops.
- Parameterize the hardcoded production RabbitMQ URL and routing keys in vars/apps/elnbuildsync.yml to support safe staging deployments.
Minor Suggestions:
- Verify if 'distrobaker.keytab' is the intended filename in keytab.yml.j2 given the service user is 'eln-buildsync'.

🤖 AI Code Review | Generated with ai-code-review | Model: gemini-3.1-pro-preview

⚠️ AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.

## AI Code Review ### Detailed Code Review The OpenShift and RabbitMQ manifests establish the deployment structure for ELNBuildSync. The architecture correctly follows existing application patterns. However, two critical configuration bugs exist that will cause failures in both deployment and message routing. Certificate filenames in the OpenShift secret mismatch the expected paths in the `fedora-messaging` TOML configuration, which will result in startup crashes. Furthermore, the TOML configuration hardcodes production URLs and routing keys, meaning any staging deployment will inadvertently connect to and process production message queues. #### 📂 File Reviews <details> <summary><strong>📄 `roles/openshift-apps/elnbuildsync/templates/fedora-messaging-config.yml.j2`</strong> - Creates the fedora-messaging secret including the TOML config and TLS certificates.</summary> - **Critical** [Bug]: The secret defines certificate keys as `elnbuildsync.crt` and `elnbuildsync.key`, but the corresponding TOML configuration (`vars/apps/elnbuildsync.yml`) expects `/etc/fedora-messaging/distrobuildsync-eln.key` and `distrobuildsync-eln.crt`. The container will crash on startup due to missing certificate files. - *Suggestion:* Update the key names in the Secret manifest to match the paths defined in the TOML configuration. ```` distrobuildsync-eln.crt: |- {{ ebs_fedora_messaging_client_pem | indent(4) }} distrobuildsync-eln.key: |- {{ ebs_fedora_messaging_client_key | indent(4) }} ```` </details> <details> <summary><strong>📄 `vars/apps/elnbuildsync.yml`</strong> - Defines application variables including the fedora-messaging configuration payload.</summary> - **Critical** [Logic]: The `ebs_fedora_messaging_config` string hardcodes the production RabbitMQ URL (`rabbitmq.fedoraproject.org`) and production routing keys (`org.fedoraproject.prod...`). A deployment to the staging cluster will incorrectly listen to production events. - *Suggestion:* Use Ansible variables (`{{ env_suffix }}` and `{{ env_short }}`) to dynamically configure the environment endpoints and routing keys in the TOML definition. ```` amqp_url = "amqps://fedora:@rabbitmq{{ env_suffix }}.fedoraproject.org/%2Fpubsub" ... routing_keys = [ "org.fedoraproject.{{ env_short }}.buildsys.repo.init", "org.fedoraproject.{{ env_short }}.buildsys.repo.done", "org.fedoraproject.{{ env_short }}.buildsys.tag", "org.fedoraproject.{{ env_short }}.buildsys.task.state.change" ] ```` </details> ### ✅ Summary - **Overall Assessment:** Critical configuration issues were identified regarding certificate filename mismatches and hardcoded production values in the message broker configuration. - **Priority Issues:** - Fix certificate filename mismatch between fedora-messaging-config.yml.j2 and the TOML configuration to prevent container crash loops. - Parameterize the hardcoded production RabbitMQ URL and routing keys in vars/apps/elnbuildsync.yml to support safe staging deployments. - **Minor Suggestions:** - Verify if 'distrobaker.keytab' is the intended filename in keytab.yml.j2 given the service user is 'eln-buildsync'. --- 🤖 **AI Code Review** | Generated with [ai-code-review](https://gitlab.com/redhat/edge/ci-cd/ai-code-review) | **Model:** `gemini-3.1-pro-preview` ⚠️ *AI-generated suggestions may be incorrect. Verify before applying. Not a replacement for human review.*

sgallagh commented

2026-06-01 21:22:22 +00:00

Author

Contributor

@kevin wrote in #3374 (comment):

There shouldn't be a need for a smtp password, you should be able to use our gateway ( bastion.fedoraproject.org ) if you are sending things.

You gave us an SMTP password previously, I assumed we would just use that.

The keytab I think you already have? should we just reuse that?

Yes, but that will have to go into the private repo, which I cannot do.

We can make the db passwords and point to the fedora-messaging files which we should already have.

Thanks.

We should probibly target staging only first, so leave os_control and the prod db out of hosts for now?

Yeah, we can (and probably should) start with staging.

@kevin wrote in https://forge.fedoraproject.org/infra/ansible/pulls/3374#issuecomment-792605: > There shouldn't be a need for a smtp password, you should be able to use our gateway ( bastion.fedoraproject.org ) if you are sending things. You gave us an SMTP password previously, I assumed we would just use that. > The keytab I think you already have? should we just reuse that? Yes, but that will have to go into the private repo, which I cannot do. > We can make the db passwords and point to the fedora-messaging files which we should already have. Thanks. > We should probibly target staging only first, so leave os_control and the prod db out of hosts for now? Yeah, we can (and probably should) start with staging.

james merged commit 3202a6b388 into main

2026-06-09 13:22:42 +00:00

No reviewers

No milestone

No project

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

infra/ansible!3374

No description provided.

Rows
Columns