UYUNI - synchronize content between registry servers
an invention by RDiasMateus
Updated over 2 years ago. 1 hackers ♥️. 3 followers.

Project Description

UYUNI has the ability to synchronize packages from remote locations. But doesn't have a similar solution for container images. This project aims to add a option to synchronize content between to registries using UYUNI, in a similar way we do we packages today.

If a user already has a local registry, uyuni can be used to synchronize content and work in air-gaped environments.

The goal is not to provide a registry "inside" uyuni.

@MC has developed in the past a formula with forms that deploys and configures a container registry from uyuni.

Goal for this Hackweek

Goal: Recurrently synchronize selected content from one registry to another. Code will be committed to a branch in uyuni repository: https://github.com/uyuni-project/uyuni/

Resources

We also have a confluence page at: https://confluence.suse.com/display/~RDiasMateus/Hack+-+Registry

Status

We decided to create a definition of a registry synchronization project, with will have a source and target registry, and then a list of images to be synchronized. For each image we can define a list of tags and/or a regex to be applyed and select wich tags should be copied between the two registries.

With this information we can have a periodic task that will use this information and perform the synchronization using the skopeo tool

Day 1:

  • We decided to use skope to perform the operations in the remote registries
  • Add command to list all repositories in a registry: https://github.com/rjmateus/skopeo/tree/list_catalog
  • Package the latest skopeo version with the patch for list-repos: https://build.opensuse.org/package/show/home:mcalmer/skopeo
  • Definition of the database model to save registry synchronization data between remote registries

Day 2:

  • Debase design and implementation
  • Integration with skopeo. Front-end API to
    • Get all images/repos from one registry
    • Get all image tags from one registry
  • Create a synchronization definition that can be used to synchronize content. Is the data definition of what should be synchronized
    • Front-end work started
    • XML-API and Json over HTTP API start

Day 3:

  • XML-API and Json over HTTP API in place to create and configure a synchronization unit
  • UI to manage syncronization units under development
  • Task to run the synchronization unit is now generating the yaml file needed for skopeo
    • Still missing the call to skopeo to perform the synchronization

Day 4:

  • Taskomatic task synchronizing images between registry
  • Keep working on front-end support
  • Keep working on API support to configure the synchronization task

Day 5:

  • Investigate how to deal with architectures.
  • Keep working on front-end support
  • XML-RPC and JSON over http API are finished, with full CRUD support to configure synchronization task

TODO

  • Endpoint to provide the list of available architectures for: registry+image+tag
  • Endpoint to provide image details for: registry+image+tag+architecture 
  • Support definition of the architecture to synchronize for sync project

Looking for hackers with the skills:

uyuni susemanager registry

This project is part of:

Hack Week 22

Activity

  • over 2 years ago: RDiasMateus joined this project.
  • over 2 years ago: RDiasMateus added keyword "uyuni" to this project.
  • over 2 years ago: RDiasMateus added keyword "susemanager" to this project.
  • over 2 years ago: RDiasMateus added keyword "registry" to this project.
  • over 2 years ago: j_renner joined this project.
  • over 2 years ago: j_renner liked this project.
  • over 2 years ago: mcalmer started this project.
  • over 2 years ago: RDiasMateus originated this project.


    • Comments

    • RDiasMateus
      over 2 years ago by RDiasMateus | Reply

      We also have a confluence page at: https://confluence.suse.com/display/~RDiasMateus/Hack+-+Registry Day One status:

      • We decided to use skope to perform the operations in the remote registries
      • Add command to list all repositories in a registry: https://github.com/rjmateus/skopeo/tree/list_catalog
      • Package the latest skopeo version with the patch for list-repos: https://build.opensuse.org/package/show/home:mcalmer/skopeo
      • Definition of the database model to save registry synchronization data between remote registries

    Similar Projects

    Flaky Tests AI Finder for Uyuni and MLM Test Suites by oscar-barrios

    Description

    Our current Grafana dashboards provide a great overview of test suite health, including a panel for "Top failed tests." However, identifying which of these failures are due to legitimate bugs versus intermittent "flaky tests" is a manual, time-consuming process. These flaky tests erode trust in our test suites and slow down development.

    This project aims to build a simple but powerful Python script that automates flaky test detection. The script will directly query our Prometheus instance for the historical data of each failed test, using the jenkins_build_test_case_failure_age metric. It will then format this data and send it to the Gemini API with a carefully crafted prompt, asking it to identify which tests show a flaky pattern.

    The final output will be a clean JSON list of the most probable flaky tests, which can then be used to populate a new "Top Flaky Tests" panel in our existing Grafana test suite dashboard.

    Goals

    By the end of Hack Week, we aim to have a single, working Python script that:

    1. Connects to Prometheus and executes a query to fetch detailed test failure history.
    2. Processes the raw data into a format suitable for the Gemini API.
    3. Successfully calls the Gemini API with the data and a clear prompt.
    4. Parses the AI's response to extract a simple list of flaky tests.
    5. Saves the list to a JSON file that can be displayed in Grafana.
    6. New panel in our Dashboard listing the Flaky tests

    Resources

    Move Uyuni Test Framework from Selenium to Playwright + AI by oscar-barrios

    Description

    This project aims to migrate the existing Uyuni Test Framework from Selenium to Playwright. The move will improve the stability, speed, and maintainability of our end-to-end tests by leveraging Playwright's modern features. We'll be rewriting the current Selenium code in Ruby to Playwright code in TypeScript, which includes updating the test framework runner, step definitions, and configurations. This is also necessary because we're moving from Cucumber Ruby to CucumberJS.

    If you're still curious about the AI in the title, it was just a way to grab your attention. Thanks for your understanding.

    Goals

    • Migrate Core tests including Onboarding of clients
    • Improve test reliabillity: Measure and confirm a significant reduction of flakynes.
    • Implement a robust framework: Establish a well-structured and reusable Playwright test framework using the CucumberJS

    Resources