infra/ansible
23
8
Fork 62
Code Pull requests 5 Activity Actions

drm-panic-frontend: Add deployment #3283

Merged
kevin merged 1 commit from jexposit/ansible:add-drm-panic-frontend into main 2026-06-02 20:51:29 +00:00
Conversation 14 Commits 1 Files changed 5 +141
jexposit commented 2026-04-15 14:29:18 +00:00
Contributor
Copy link

Hi!

This MR includes the required changes to deploy the DRM Panic Frontend.

For more details, please check infra/tickets#13254

WIP because:

  • This is the first time in my life I work with Ansible. I copy & pasted the code from "asknot" and adapted it, but I'd appreciate a review from somebody with experience
  • route_host: I'm not sure which URL should I pick
  • project_appowners: Again, I'm not sure if I should be in the list or if I missed an admin

To support this deployment, in the DRM Panic Frontend repo, I added a Dockerfile:
https://github.com/JoseExposito/drm-panic-frontend/pull/2

I'm not sure if it meets with the expectations to be deployed in your infra or you have other requirements, like selecting a different base image.

Thanks a lot in advance for your feedback.

Hi! This MR includes the required changes to deploy the DRM Panic Frontend. For more details, please check https://forge.fedoraproject.org/infra/tickets/issues/13254 WIP because: - This is the first time in my life I work with Ansible. I copy & pasted the code from "asknot" and adapted it, but I'd appreciate a review from somebody with experience - `route_host`: I'm not sure which URL should I pick - `project_appowners`: Again, I'm not sure if I should be in the list or if I missed an admin To support this deployment, in the DRM Panic Frontend repo, I added a Dockerfile: https://github.com/JoseExposito/drm-panic-frontend/pull/2 I'm not sure if it meets with the expectations to be deployed in your infra or you have other requirements, like selecting a different base image. Thanks a lot in advance for your feedback.
drm-panic-frontend: Add deployment
All checks were successful
Linter / yamllint (pull_request) Successful in 24s
Details
Linter / ansible-lint (pull_request) Successful in 45s
Details
AI Code Review / ai-review (pull_request_target) Has been skipped
Details
af683bdeae
zlopez commented 2026-04-17 08:04:49 +00:00
Owner
Copy link

@jexposit wrote in #3283 (comment):

  • route_host: I'm not sure which URL should I pick

route_host for staging should be drm-panic.stg.fedoraproject.org and I recommend going with something like coreos-cincinnati project

  - role: openshift/route
    route_app: coreos-cincinnati
    route_name: coreos-updates
    route_host: "updates.coreos{{ env_suffix }}.fedoraproject.org"
    route_serviceport: coreos-cincinnati-updates
    route_servicename: coreos-cincinnati
  • project_appowners: Again, I'm not sure if I should be in the list or if I missed an admin

project_appowners define people who are owner of the project in OpenShift. You should be there as the person who is maintaining the deployment. You don't need to include me or other admins as we have the access anyway.

@jexposit wrote in https://forge.fedoraproject.org/infra/ansible/pulls/3283#issue-113084: > * `route_host`: I'm not sure which URL should I pick `route_host` for staging should be `drm-panic.stg.fedoraproject.org` and I recommend going with something like coreos-cincinnati project ``` - role: openshift/route route_app: coreos-cincinnati route_name: coreos-updates route_host: "updates.coreos{{ env_suffix }}.fedoraproject.org" route_serviceport: coreos-cincinnati-updates route_servicename: coreos-cincinnati ``` > * `project_appowners`: Again, I'm not sure if I should be in the list or if I missed an admin `project_appowners` define people who are owner of the project in OpenShift. You should be there as the person who is maintaining the deployment. You don't need to include me or other admins as we have the access anyway.
jexposit commented 2026-04-17 08:15:14 +00:00
Author
Contributor
Copy link

Thanks a lot for your review @zlopez !

I update the MR with the following changes:

  • project_appowners: Only myself
  • route_host: Set to drm-panic{{ env_suffix }}.fedoraproject.org. env_suffix is .stg in stage and empty string in production, so it generates the desired URLs.

To make it easier to review the changes, I pushed a second time rebasing on top of main and removed the "WIP" tag.

Thanks a lot for your review @zlopez ! I update the MR with the following changes: - `project_appowners`: Only myself - `route_host`: Set to `drm-panic{{ env_suffix }}.fedoraproject.org`. `env_suffix` is `.stg` in stage and empty string in production, so it generates the desired URLs. To make it easier to review the changes, I pushed a second time rebasing on top of main and removed the "WIP" tag.
jexposit force-pushed add-drm-panic-frontend from af683bdeae
All checks were successful
Linter / yamllint (pull_request) Successful in 24s
Details
Linter / ansible-lint (pull_request) Successful in 45s
Details
AI Code Review / ai-review (pull_request_target) Has been skipped
Details
to c350d2c435
Some checks failed
Linter / yamllint (pull_request) Successful in 26s
Details
Linter / ansible-lint (pull_request) Has been cancelled
Details
2026-04-17 08:15:14 +00:00 Compare
jexposit changed title from WIP: drm-panic-frontend: Add deployment to drm-panic-frontend: Add deployment 2026-04-17 08:15:47 +00:00
jexposit force-pushed add-drm-panic-frontend from c350d2c435
Some checks failed
Linter / yamllint (pull_request) Successful in 26s
Details
Linter / ansible-lint (pull_request) Has been cancelled
Details
to c7277a6711
All checks were successful
Linter / yamllint (pull_request) Successful in 25s
Details
Linter / ansible-lint (pull_request) Successful in 45s
Details
2026-04-17 08:16:40 +00:00 Compare
zlopez requested changes 2026-04-17 13:16:01 +00:00
zlopez left a comment
Copy link

One more thing I found.

One more thing I found.
playbooks/openshift-apps/drm-panic-frontend.yml Outdated
@ -0,0 +47,4 @@
route_servicename: drm-panic-frontend
when: env == "staging"
- role: openshift/route
zlopez commented 2026-04-17 13:13:52 +00:00
Owner
Copy link

You don't need second openshift/route role as they are now idenitical.

You don't need second openshift/route role as they are now idenitical.
jexposit commented 2026-04-17 15:10:32 +00:00
Author
Contributor
Copy link

Good point. I dropped the second openshift/route and the "when" condition so it applies to both environments.

Good point. I dropped the second openshift/route and the "when" condition so it applies to both environments.
jexposit force-pushed add-drm-panic-frontend from c7277a6711
All checks were successful
Linter / yamllint (pull_request) Successful in 25s
Details
Linter / ansible-lint (pull_request) Successful in 45s
Details
to b092d97256
All checks were successful
Linter / yamllint (pull_request) Successful in 25s
Details
Linter / ansible-lint (pull_request) Successful in 45s
Details
2026-04-17 15:09:48 +00:00 Compare
jexposit commented 2026-04-29 09:15:12 +00:00
Author
Contributor
Copy link

Hi @zlopez

I'll be away from keyboard the last 3 weeks of May. Once I'm back, we'll have ~1 month before Fedora 45 is branched to include the kernel side changes, i.e., change the DRM Panic configuration to point to drm-panic.fedoraproject.org.

I was wondering, is "drm-panic.fedoraproject.org" going to be the final URL? If so, it'd be nice to start evaluating the required changes on the kernel. With people going on summer PTO, I would prefer to start looking into this sooner rather than latter.

Hi @zlopez I'll be away from keyboard the last 3 weeks of May. Once I'm back, we'll have ~1 month before Fedora 45 is branched to include the kernel side changes, i.e., change the DRM Panic configuration to point to drm-panic.fedoraproject.org. I was wondering, is "drm-panic.fedoraproject.org" going to be the final URL? If so, it'd be nice to start evaluating the required changes on the kernel. With people going on summer PTO, I would prefer to start looking into this sooner rather than latter.
zlopez commented 2026-04-29 10:33:04 +00:00
Owner
Copy link

@jexposit
The freeze will end today probably, but I will be out tomorrow and on Friday. We can start looking into this next week. But I think the URL can stay, if you don't want to change something.

@jexposit The freeze will end today probably, but I will be out tomorrow and on Friday. We can start looking into this next week. But I think the URL can stay, if you don't want to change something.
jexposit commented 2026-04-29 14:26:07 +00:00
Author
Contributor
Copy link

Cool! Lets comment on this next week. No changes required from my side.

Cool! Lets comment on this next week. No changes required from my side.
jexposit commented 2026-05-07 13:56:56 +00:00
Author
Contributor
Copy link

Following-up a bit on this topic, the kernel MR was created by Jocelyn here:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4510

It is in draft until this is merged and we can test the end result.

Following-up a bit on this topic, the kernel MR was created by Jocelyn here: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4510 It is in draft until this is merged and we can test the end result.
jfalempe commented 2026-05-21 07:18:49 +00:00
First-time contributor
Copy link

The kernel-ark MR is now merged:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4510

But the QR code now redirect to https://drm-panic.fedoraproject.org, which doesn't exist yet.

The kernel-ark MR is now merged: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/4510 But the QR code now redirect to https://drm-panic.fedoraproject.org, which doesn't exist yet.
jexposit commented 2026-06-01 08:20:00 +00:00
Author
Contributor
Copy link

@zlopez I think all the pieces are in place but the frontend itself. Let me know if there is something missing before we can merge this.

@zlopez I think all the pieces are in place but the frontend itself. Let me know if there is something missing before we can merge this.
kevin commented 2026-06-01 21:02:06 +00:00
Owner
Copy link

a few comments:

  • it's probibly best to just deploy this for staging at first. So, remove the os_control hosts keeping only os_control_stg
  • drm-panic{{ env_suffix }}.fedoraproject.org will need to be added to dns

Otherwise looks fine to me.

a few comments: - it's probibly best to just deploy this for staging at first. So, remove the os_control hosts keeping only os_control_stg - drm-panic{{ env_suffix }}.fedoraproject.org will need to be added to dns Otherwise looks fine to me.
jexposit force-pushed add-drm-panic-frontend from b092d97256
All checks were successful
Linter / yamllint (pull_request) Successful in 25s
Details
Linter / ansible-lint (pull_request) Successful in 45s
Details
to b3b48bc8fa
Some checks failed
Linter / ansible-lint (pull_request) Has been cancelled
Details
Linter / yamllint (pull_request) Has been cancelled
Details
2026-06-02 05:28:48 +00:00 Compare
jexposit force-pushed add-drm-panic-frontend from b3b48bc8fa
Some checks failed
Linter / ansible-lint (pull_request) Has been cancelled
Details
Linter / yamllint (pull_request) Has been cancelled
Details
to be4649d54a
All checks were successful
Linter / yamllint (pull_request) Successful in 26s
Details
Linter / ansible-lint (pull_request) Successful in 1m28s
Details
AI Code Review / ai-review (pull_request_target) Successful in 27s
Details
2026-06-02 05:29:28 +00:00 Compare
jexposit commented 2026-06-02 05:32:18 +00:00
Author
Contributor
Copy link

Thanks @kevin, I pushed the suggested change to deploy the frontend in staging only. To make the review process easier, the first push contains the change and the second one is a rebase on top of main.

drm-panic{{ env_suffix }}.fedoraproject.org will need to be added to dns

Is that change handled in this repo? I couldn't find the right place to include this change.

Thanks @kevin, I pushed the suggested change to deploy the frontend in staging only. To make the review process easier, the first push contains the change and the second one is a rebase on top of main. > drm-panic{{ env_suffix }}.fedoraproject.org will need to be added to dns Is that change handled in this repo? I couldn't find the right place to include this change.
kevin commented 2026-06-02 20:50:05 +00:00
Owner
Copy link

DNS is in another repo. I can handle adding those hosts...

Lets give this a go in staging.

DNS is in another repo. I can handle adding those hosts... Lets give this a go in staging.
forgejo-actions commented 2026-06-02 20:50:44 +00:00
Copy link

AI Code Review

Detailed Code Review

The configuration correctly implements the staging-first deployment strategy requested during the review discussions. The use of standard Fedora infrastructure variables, particularly env_suffix in the routing layer, appropriately DRYs up the code and future-proofs it for production deployment.

The OpenShift objects (Service, ImageStream, BuildConfig, and Deployment) are correctly wired together. The BuildConfig correctly references the GitHub repository and dynamically selects the target branch based on the environment. One minor area for improvement is adding resource boundaries to the Deployment spec to ensure the pod doesn't consume unbounded resources on the OpenShift nodes.

📂 File Reviews

📄 `roles/openshift-apps/drm-panic-frontend/files/deployment.yml` - Kubernetes Deployment specification for the frontend.
  • Minor [Suggestion]: The deployment is missing container resource requests and limits. Adding these is considered a Kubernetes/OpenShift best practice to ensure fair scheduling and prevent a single container from causing OOM (Out of Memory) issues on the worker nodes.
    • Suggestion: Add a resources block defining reasonable memory and CPU limits based on expected consumption.
      containers:
      - name: drm-panic-frontend
        image: image-registry.openshift-image-registry.svc:5000/drm-panic-frontend/drm-panic-frontend:latest
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "100m"

✅ Summary

  • Overall Assessment: The deployment logic is sound, correctly restricts to the staging environment as discussed, and has no critical bugs or security risks identified. Review complete.
  • Minor Suggestions:
    • Consider adding resource requests and limits (cpu, memory) to the container specification in deployment.yml to improve OpenShift scheduling and cluster stability.

🤖 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 configuration correctly implements the staging-first deployment strategy requested during the review discussions. The use of standard Fedora infrastructure variables, particularly `env_suffix` in the routing layer, appropriately DRYs up the code and future-proofs it for production deployment. The OpenShift objects (Service, ImageStream, BuildConfig, and Deployment) are correctly wired together. The BuildConfig correctly references the GitHub repository and dynamically selects the target branch based on the environment. One minor area for improvement is adding resource boundaries to the Deployment spec to ensure the pod doesn't consume unbounded resources on the OpenShift nodes. #### 📂 File Reviews <details> <summary><strong>📄 `roles/openshift-apps/drm-panic-frontend/files/deployment.yml`</strong> - Kubernetes Deployment specification for the frontend.</summary> - **Minor** [Suggestion]: The deployment is missing container resource requests and limits. Adding these is considered a Kubernetes/OpenShift best practice to ensure fair scheduling and prevent a single container from causing OOM (Out of Memory) issues on the worker nodes. - *Suggestion:* Add a `resources` block defining reasonable memory and CPU limits based on expected consumption. ```` containers: - name: drm-panic-frontend image: image-registry.openshift-image-registry.svc:5000/drm-panic-frontend/drm-panic-frontend:latest ports: - containerPort: 8080 resources: requests: memory: "64Mi" cpu: "50m" limits: memory: "128Mi" cpu: "100m" ```` </details> ### ✅ Summary - **Overall Assessment:** The deployment logic is sound, correctly restricts to the staging environment as discussed, and has no critical bugs or security risks identified. Review complete. - **Minor Suggestions:** - Consider adding resource requests and limits (cpu, memory) to the container specification in `deployment.yml` to improve OpenShift scheduling and cluster stability. --- 🤖 **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.*
kevin merged commit 6a1a255d9f into main 2026-06-02 20:51:29 +00:00
kevin commented 2026-06-02 20:55:26 +00:00
Owner
Copy link

And it's up: https://drm-panic.stg.fedoraproject.org/

And it's up: https://drm-panic.stg.fedoraproject.org/
Sign in to join this conversation.
Reviewers
No reviewers
zlopez
Labels
Clear labels   
ai-review-please
label for requesting AI code review

  
freeze-break-request

   
post-freeze
  
Backlog Status
Needs Review
 Work items that have been created or updated but need review, refinement, or approval before they can be considered ready for sprint planning.

  
Backlog Status
Ready
 Work items that have been reviewed, refined, and are ready to be committed to a sprint. These items have clear requirements and can be worked on immediately when capacity is available.

  
chore
Work that needs to be done but doesn't add new functionality or fix bugs. Maintenance tasks that keep the system running smoothly and the codebase clean.

  
documentation
Work focused on creating, updating, or improving documentation for users, developers, or system administrators.

  
points
01
 A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  
points
02
 This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  
points
03
 Medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  
points
05
 A significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  
points
08
 Complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  
points
13
 Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint and should be broken down.

  
Priority
High
 This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  
Priority
Low
 This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  
Priority
Medium
 This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  
Sprint Status
Blocked
 Work items that cannot progress due to external dependencies, blockers, or issues that need resolution.

  
Sprint Status
Done
 Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  
Sprint Status
In Progress
 Work items currently being worked on by a team member. Active development, research, or implementation is happening.

  
Sprint Status
Review
 Work items that are complete but need review, testing, or approval before being marked as done.

  
Sprint Status
To Do
 Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  
Technical Debt
Work that addresses shortcuts, workarounds, or suboptimal implementations that were done previously to meet deadlines. These items improve code quality, maintainability, or performance without adding new features.

  
Work Item
Bug
 Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  
Work Item
Epic
 Large initiatives that are broken down into multiple smaller work items (user stories, tasks, bugs). Epics represent significant features or projects that span multiple sprints.

  
Work Item
Spike
 Time-boxed research, investigation, or proof-of-concept work to reduce uncertainty or explore solutions. Spikes help inform future development decisions.

  
Work Item
Task
 Used to break down larger user stories into smaller, manageable implementation pieces. They focus on the specific technical steps needed to deliver the user story's value.

  
Work Item
User Story
 User-facing features or functionality that can be framed from a user perspective, describing what someone wants to accomplish and why.

No labels
ai-review-please
freeze-break-request
post-freeze
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 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!3283
No description provided.