#149 - [Gonothi]: RAG Mini-Project - explore deploying on Quay.io - commops/interns

cybette commented

2026-05-26 21:34:05 +00:00

Owner

Summary

For the OCI image(s) created via the RamaLama RAG pipeline, make them available on quay.io for distribution

Background

Related to #146, please refer to the background details therein. This issue is specific to the "Quay-ification" of the mini-project 😄

Deliverables

Create container repositories under your own namespace on quay.io (e.g. quay.io/gtfrans2re/fedora-commblog-rag)
Tag and push the OCI image(s) you have already created locally to the Quay registry (podman push)
Alternatively, use ramalama rag to regenerate the OCI image and push it directly to the corresponding quay.io repo
Test your streamlit app / Jupyter notebook with oci_image / RAG_IMAGES pointing to quay.io instead of localhost
Write a quickstart guide for users (mentors and editors) to utilize your app / notebook and the quay images, without having to run through the whole process (fetch articles, Docling ingest, build RAG vector stores etc.)

Optional for mini-project

Research the solutions and share your findings in a comment here, but implementation not needed for completion

Explore options to trigger building of new OCI images (e.g. when the article writing guides have been modified or new blog posts added) and push updates Quay
Related to triggering new builds, check for ways to track changes in the (multiple) guideline sources, also briefly discussed in this issue
Determine if this process is similar for GitHub and Forgejo
Work with @cybette to move mini-project from GitHub to Forgejo
While waiting for GPU host access, check out Infrastructure Apprentice if you have time

Outcome

RAG images are added to the Quay registry making them accessible to other users

### Summary For the OCI image(s) created via the RamaLama RAG pipeline, make them available on quay.io for distribution ### Background Related to #146, please refer to the background details therein. This issue is specific to the "Quay-ification" of the mini-project 😄 ### Deliverables - [x] Create container repositories under your own namespace on quay.io (e.g. `quay.io/gtfrans2re/fedora-commblog-rag`) - [x] Tag and push the OCI image(s) you have already created locally to the Quay registry (`podman push`) - [x] Alternatively, use `ramalama rag` to regenerate the OCI image and push it directly to the corresponding quay.io repo - [x] Test your streamlit app / Jupyter notebook with `oci_image` / `RAG_IMAGES` pointing to quay.io instead of localhost - [x] Write a quickstart guide for users (mentors and editors) to utilize your app / notebook and the quay images, without having to run through the whole process (fetch articles, Docling ingest, build RAG vector stores etc.) ### Optional for mini-project Research the solutions and share your findings in a comment here, but implementation not needed for completion - [x] Explore options to trigger building of new OCI images (e.g. when the article writing guides have been modified or new blog posts added) and push updates Quay - [x] Related to triggering new builds, check for ways to track changes in the (multiple) guideline sources, also briefly discussed [in this issue](https://github.com/gtfrans2re/fedora-commblog-rag/issues/1#issuecomment-4576038618) - [x] Determine if this process is similar for GitHub and Forgejo - [x] Work with @cybette to move mini-project from GitHub to Forgejo - [x] While waiting for GPU host access, check out [Infrastructure Apprentice](https://docs.fedoraproject.org/en-US/infra/join_guide/apprentice/) if you have time ### Outcome RAG images are added to the Quay registry making them accessible to other users

cybette added the

scope

new

label

2026-05-26 21:34:05 +00:00

cybette added this to the 2026 Sprint 6 (May 25–June 5) milestone

2026-05-26 21:36:09 +00:00

cybette added this to the 2026 Intern Sprint Planning (Sprints 1–8) project

2026-05-26 21:36:15 +00:00

gtfrans2re was assigned by cybette

2026-05-26 21:37:06 +00:00

cybette added the due date 2026-06-05

2026-05-26 21:37:20 +00:00

cybette commented

2026-05-26 22:34:06 +00:00

Author

Owner

@dominikkawka please check if everything is technically sound from RamaLama pov.

Do you have any updates about the ramalama rag rewrite (I'm assuming it's in addition to this one merged in April which already contains some major internal pipeline changes)? I think we are more concerned with possible changes (especially removal) in config options which may affect how we use it. And whether it affects ramalama run/serve --rag

@dominikkawka please check if everything is technically sound from RamaLama pov. Do you have any updates about the `ramalama rag` rewrite (I'm assuming it's in addition to [this one](https://github.com/containers/ramalama/pull/2564) merged in April which already contains some major internal pipeline changes)? I think we are more concerned with possible changes (especially removal) in config options which may affect how we use it. And whether it affects `ramalama run/serve --rag`

❤️ 1

gtfrans2re commented

2026-05-27 06:06:56 +00:00

Collaborator

Hello, @cybette! Thank you for creating this issue and for assigning it to me. I am on it and will keep checking off the items in the checklist above as I go and comment on my progress in this issue thread. Thanks in advance to @dominikkawka for the technical check from the RamaLama POV.

👍 1

gtfrans2re commented

2026-05-28 13:55:32 +00:00

Collaborator

Dear mentor @cybette,

I created container repositories under my namespace and tagged and pushed the OCI images I created locally to the Quay registry with podman push. You will find them all on the quay. Also, I tested the Streamlit web app and Jupyter notebook with oci_image / RAG_IMAGES pointing to quay.io instead of localhost. Right now, the mini-project repository on GitHub has the latest version of the system codebase with changes made from the source issue you raised there. Anyone can now use it by pointing to quay, and it would work.

More updates will follow for the remaining deliverables!

Dear mentor @cybette, I created container repositories under my [namespace](https://quay.io/user/gtfrans2re/) and tagged and pushed the OCI images I created locally to the Quay registry with podman push. You will find them all on the quay. Also, I tested the Streamlit web app and Jupyter notebook with oci_image / RAG_IMAGES pointing to quay.io instead of localhost. Right now, the mini-project repository on GitHub has the latest version of the system codebase with changes made from the source issue you raised there. Anyone can now use it by pointing to quay, and it would work. More updates will follow for the remaining deliverables!

👍 1

cybette modified the due date from 2026-06-05 to 2026-06-08

2026-06-05 12:51:16 +00:00

gtfrans2re commented

2026-06-05 18:58:32 +00:00

Collaborator

Hello, @cybette! Wanted to give an update regarding the exploration of the Fedora Infrastructure Apprentice. I applied today for the infra team to give me access by filling out this ticket: https://forge.fedoraproject.org/infra/tickets/issues/13393, and I think you, @jflory7, or @dominikkawka, can help me gain access faster by vouching for me as discussed in the Matrix internship room. Regarding moving the project from GitHub to Forgejo, we are also working on it together as per our Matrix discussion.

Hello, @cybette! Wanted to give an update regarding the exploration of the Fedora Infrastructure Apprentice. I applied today for the infra team to give me access by filling out this ticket: [https://forge.fedoraproject.org/infra/tickets/issues/13393](https://forge.fedoraproject.org/infra/tickets/issues/13393), and I think you, @jflory7, or @dominikkawka, can help me gain access faster by vouching for me as discussed in the Matrix internship room. Regarding moving the project from GitHub to Forgejo, we are also working on it together as per our Matrix discussion.

gtfrans2re commented

2026-06-05 18:59:12 +00:00

Collaborator

Hello, @cybette! Wanted to give an update regarding the exploration of the Fedora Infrastructure Apprentice. I applied today for the infra team to give me access by filling out this ticket: https://forge.fedoraproject.org/infra/tickets/issues/13393, and I think you, @jflory7, or @dominikkawka, can help me gain access faster by vouching for me as discussed in the Matrix internship room. Regarding moving the project from GitHub to Forgejo, we are also working on it together as per our Matrix discussion.

Hello, @cybette! Wanted to give an update regarding the exploration of the Fedora Infrastructure Apprentice. I applied today for the infra team to give me access by filling out this ticket: [https://forge.fedoraproject.org/infra/tickets/issues/13393](https://forge.fedoraproject.org/infra/tickets/issues/13393), and I think you, @jflory7, or @dominikkawka, can help me gain access faster by vouching for me as discussed in the Matrix internship room. Regarding moving the project from GitHub to Forgejo, we are also working on it together as per our Matrix discussion.

gtfrans2re commented

2026-06-09 04:05:22 +00:00

Collaborator

Hello, @cybette! Here are my research findings on the optional items (rebuild triggers, source tracking, and GitHub/Forgejo parity). As implementation isn't required for completion, this is a written summary of the options:

1. Triggering new OCI image builds when sources change

The goal: when the guidelines or articles change, rebuild the RAG image and push the update to Quay automatically. Options, roughly in increasing order of automation:

Manual / documented (current state): re-run ramalama rag --chunk-size 100 <corpus> <quay-image> then podman push. Simple, reproducible, and fine given how rarely the sources change.
Scheduled CI job: a CI pipeline (GitHub Actions or Forgejo Actions) on a cron schedule that re-fetches, rebuilds, and pushes. Needs a Quay robot account credential stored as a CI secret.
Change-triggered CI: instead of a blind schedule, only rebuild when a source actually changed (see source-tracking below), which avoids pushing identical images.

Quay itself can also build from a Dockerfile/Containerfile on a Git push (Quay build triggers), but since our images are produced by ramalama rag rather than a plain container build, a CI job that runs ramalama and pushes is the better fit.

2. Tracking changes in the (multiple) guideline sources

This ties into the reproducibility point you pointed out, @cybette. The two sources need different mechanisms:

Community Blog guidelines (WordPress): poll the WordPress REST API and compare the page's modified timestamp (and/or a content hash) against the last build. This is likely where an API key helps for reliable polling.
Fedora Magazine guidelines (Forge): watch commits to the source .adoc file at https://forge.fedoraproject.org/magazine/fedora-magazine/src/branch/main/modules/ROOT/pages/writing-guidelines.adoc — more direct and dependable than scraping the rendered docs page (which is also bot-protected).

Applying minor-vs-major distinction as suggested: typo/phrasing fixes that don't change meaning don't warrant a rebuild; structural changes (for instance, a new review process) do.

3. Is the process similar for GitHub and Forgejo?

Largely yes. Both support a CI/Actions system that can run the same steps (fetch → ramalama rag → podman push). Key differences:

GitHub — GitHub Actions, a mature marketplace of prebuilt actions, secrets stored in repo settings.
Forgejo — Forgejo Actions is largely GitHub-Actions-compatible (same workflow YAML syntax), so a workflow written for GitHub usually ports with minimal changes. Runners must be provisioned/available on the Forge instance, and secrets are stored in Forgejo's repo settings.

Since the project is migrating to the Fedora Forge (Forgejo), I'd target a Forgejo Actions workflow for any future automation, reusing the same ramalama + podman steps.

4. Migrating the repo from GitHub to Forgejo

We are already coordinating with the mentors on this. The plan is to create the repo under the appropriate Forge group (ai-ml-sig), push the existing history, re-point the README/docs links, and confirm the Quay push still works from the new location.

Net recommendation is to keep rebuilds manual/documented for now (since sources change rarely), and revisit a Forgejo Actions job once the repo has migrated. GPU/server hardware is in place.

Hello, @cybette! Here are my research findings on the optional items (rebuild triggers, source tracking, and GitHub/Forgejo parity). As implementation isn't required for completion, this is a written summary of the options: ## 1. Triggering new OCI image builds when sources change The goal: when the guidelines or articles change, rebuild the RAG image and push the update to Quay automatically. Options, roughly in increasing order of automation: - **Manual / documented (current state):** re-run `ramalama rag --chunk-size 100 <corpus> <quay-image>` then `podman push`. Simple, reproducible, and fine given how rarely the sources change. - **Scheduled CI job:** a CI pipeline (GitHub Actions or Forgejo Actions) on a cron schedule that re-fetches, rebuilds, and pushes. Needs a Quay robot account credential stored as a CI secret. - **Change-triggered CI:** instead of a blind schedule, only rebuild when a source actually changed (see source-tracking below), which avoids pushing identical images. Quay itself can also **build from a Dockerfile/Containerfile on a Git push** (Quay build triggers), but since our images are produced by `ramalama rag` rather than a plain container build, a CI job that runs ramalama and pushes is the better fit. ## 2. Tracking changes in the (multiple) guideline sources This ties into the reproducibility point you pointed out, @cybette. The two sources need different mechanisms: - **Community Blog guidelines** (WordPress): poll the WordPress REST API and compare the page's `modified` timestamp (and/or a content hash) against the last build. This is likely where an API key helps for reliable polling. - **Fedora Magazine guidelines** (Forge): watch commits to the source `.adoc` file at https://forge.fedoraproject.org/magazine/fedora-magazine/src/branch/main/modules/ROOT/pages/writing-guidelines.adoc — more direct and dependable than scraping the rendered docs page (which is also bot-protected). Applying minor-vs-major distinction as suggested: typo/phrasing fixes that don't change meaning don't warrant a rebuild; structural changes (for instance, a new review process) do. ## 3. Is the process similar for GitHub and Forgejo? Largely yes. Both support a CI/Actions system that can run the same steps (fetch → `ramalama rag` → `podman push`). Key differences: - **GitHub** — GitHub Actions, a mature marketplace of prebuilt actions, secrets stored in repo settings. - **Forgejo** — Forgejo Actions is largely GitHub-Actions-compatible (same workflow YAML syntax), so a workflow written for GitHub usually ports with minimal changes. Runners must be provisioned/available on the Forge instance, and secrets are stored in Forgejo's repo settings. Since the project is migrating to the Fedora Forge (Forgejo), I'd target a **Forgejo Actions workflow** for any future automation, reusing the same ramalama + podman steps. ## 4. Migrating the repo from GitHub to Forgejo We are already coordinating with the mentors on this. The plan is to create the repo under the appropriate Forge group (ai-ml-sig), push the existing history, re-point the README/docs links, and confirm the Quay push still works from the new location. --- Net recommendation is to keep rebuilds **manual/documented for now** (since sources change rarely), and revisit a Forgejo Actions job once the repo has migrated. GPU/server hardware is in place.

gtfrans2re commented

2026-06-09 04:15:05 +00:00

Collaborator

Also, @cybette, the Quickstart guide is done.

I've added docs/QUICKSTART.md, written for mentors and editors who just want to use the tool without running the whole pipeline (no fetching articles, no Docling ingest, no building vector stores). It walks through:

Pulling a model (Gemma 4 E4B or Granite 4 Micro)
Running the assistant directly against the pre-built Quay images with ramalama run --rag quay.io/gtfrans2re/fedora-commblog-rag <model>
An alternative path using the Streamlit web UI
A short troubleshooting table

It's referenced from the README in three places, so users land on it easily:

A callout right under the Overview ("Just want to use the tool? See docs/QUICKSTART.md")
A dedicated Quickstart section near the top with the minimal pull-and-run commands
An entry in the Table of Contents and the project-structure tree

The README also keeps the full pipeline in GUIDE.md for anyone who wants to rebuild or update the images from source, so the two guides are cleanly separated: QUICKSTART = use, GUIDE = reproduce.

Also, @cybette, the Quickstart guide is done. I've added **[docs/QUICKSTART.md](https://github.com/gtfrans2re/fedora-commblog-rag/blob/main/docs/QUICKSTART.md)**, written for mentors and editors who just want to *use* the tool without running the whole pipeline (no fetching articles, no Docling ingest, no building vector stores). It walks through: - Pulling a model (Gemma 4 E4B or Granite 4 Micro) - Running the assistant directly against the pre-built Quay images with `ramalama run --rag quay.io/gtfrans2re/fedora-commblog-rag <model>` - An alternative path using the Streamlit web UI - A short troubleshooting table It's referenced from the README in three places, so users land on it easily: - A callout right under the Overview ("Just want to use the tool? See docs/QUICKSTART.md") - A dedicated **Quickstart** section near the top with the minimal pull-and-run commands - An entry in the Table of Contents and the project-structure tree The README also keeps the full pipeline in [GUIDE.md](https://github.com/gtfrans2re/fedora-commblog-rag/blob/main/docs/GUIDE.md) for anyone who wants to rebuild or update the images from source, so the two guides are cleanly separated: QUICKSTART = use, GUIDE = reproduce.

👍 1

cybette commented

2026-06-09 11:48:59 +00:00

Author

Owner

I will check the guides, and the comments on the optional items. Will create new issues if needed.

❤️ 1

gtfrans2re commented

2026-06-10 04:59:57 +00:00

Collaborator

Sure! Thanks in advance, @cybette. We will be all ears.

gtfrans2re referenced this issue

2026-06-23 10:34:14 +00:00

[Gonothi] Familiarize more with AI/ML SIG, and Packaging process #150

cybette commented

2026-06-23 11:24:31 +00:00

Author

Owner

Forgejo repo created: https://forge.fedoraproject.org/ai-ml/editorial-guide-ramalama

Will opena new issue for the migration in next sprint.

Forgejo repo created: https://forge.fedoraproject.org/ai-ml/editorial-guide-ramalama Will opena new issue for the migration in next sprint.

cybette closed this issue

2026-06-23 11:24:32 +00:00

gtfrans2re commented

2026-06-23 16:48:17 +00:00

Collaborator

Thanks, @cybette! Great to see the Forge repo up at ai-ml/editorial-guide-ramalama. I'll keep my work ready to migrate over and pick up the migration in the new issue next sprint. Thanks for setting this up!

Thanks, @cybette! Great to see the Forge repo up at [ai-ml/editorial-guide-ramalama](https://forge.fedoraproject.org/ai-ml/editorial-guide-ramalama). I'll keep my work ready to migrate over and pick up the migration in the new issue next sprint. Thanks for setting this up!