openSUSE & SLE support for Puppet modules located at the Forge
a project by tampakrap
Updated over 6 years ago. 2 hacker ♥️.

Description

One of the PuppetLabs guys is trying to enforce best practices on administering Puppet modules, by using base modules and build services and roles on top of them. That way we can re-use external / third-party modules from forge.puppetlabs.com, ideally without touching them at all. He names that "the Lego approach". Full article.

The goal of this Hack Week project is to gather a few third-party modules, and test them for SLE and openSUSE. That way we can have a number of base modules, that are ready for constructing services and roles on top of them. Most of the good modules are written by PuppetLabs or their operations team. The problem is that most of the modules on forge have minimal to no openSUSE support, due to the fact that PuppetLabs operations are using Debian in their boxes. The good part though is that PuppetLabs is very cooperative in accepting patches, so ideally we will need to work on those modules and submit our patches upstream.

List of Puppet modules for hacking:

Related material

  • Script to deploy Puppet Master
  • Script to deploy Puppet Agent
  • There are already two SLE11SP2 and two openSUSE 12.3 VMs set up, along with a Debian VM to check the behavior of the upstream modules.
  • zypprepo Puppet module
  • r10k: A general purpose toolset for deploying Puppet environments and modules

Join this project

Looking for hackers with the skills:

puppet ruby

This project is part of:

Hack Week 10

Activity

  • over 10 years ago: yac disliked this project.
  • about 12 years ago: vdziewiecki liked this project.
  • about 12 years ago: yac liked this project.
  • about 12 years ago: tampakrap liked this project.
  • about 12 years ago: tampakrap started this project.
  • about 12 years ago: tampakrap added keyword "puppet" to this project.
  • about 12 years ago: tampakrap added keyword "ruby" to this project.
  • about 12 years ago: tampakrap originated this project.


    • Comments

    Be the first to comment!

    Similar Projects

    Recipes catalog and calculator in Rails 8 by gfilippetti

    My wife needs a website to catalog and sell the products of her upcoming bakery, and I need to learn and practice modern Rails. So I'm using this Hack Week to build a modern store using the latest Ruby on Rails best practices, ideally up to the deployment.

    TO DO

    • Index page
    • Product page
    • Admin area -- Supplies calculator based on orders -- Orders notification
    • Authentication
    • Payment
    • Deployment

    Day 1

    As my Rails knowledge was pretty outdated and I had 0 experience with Turbo (wich I want to use in the app), I started following a turbo-rails course. I completed 5 of 11 chapters.

    Day 2

    Continued the course until chapter 8 and added live updates & an empty state to the app. I should finish the course on day 3 and start my own project with the knowledge from it.

    Hackweek 24

    For this Hackweek I'll continue this project, focusing on a Catalog/Calculator for my wife's recipes so she can use for her Café.

    Day 1

    RMT.rs: High-Performance Registration Path for RMT using Rust by gbasso

    Description

    The SUSE Repository Mirroring Tool (RMT) is a critical component for managing software updates and subscriptions, especially for our Public Cloud Team (PCT). In a cloud environment, hundreds or even thousands of new SUSE instances (VPS/EC2) can be provisioned simultaneously. Each new instance attempts to register against an RMT server, creating a "thundering herd" scenario.

    We have observed that the current RMT server, written in Ruby, faces performance issues under this high-concurrency registration load. This can lead to request overhead, slow registration times, and outright registration failures, delaying the readiness of new cloud instances.

    This Hackweek project aims to explore a solution by re-implementing the performance-critical registration path in Rust. The goal is to leverage Rust's high performance, memory safety, and first-class concurrency handling to create an alternative registration endpoint that is fast, reliable, and can gracefully manage massive, simultaneous request spikes.

    The new Rust module will be integrated into the existing RMT Ruby application, allowing us to directly compare the performance of both implementations.

    Goals

    The primary objective is to build and benchmark a high-performance Rust-based alternative for the RMT server registration endpoint.

    Key goals for the week:

    1. Analyze & Identify: Dive into the SUSE/rmt Ruby codebase to identify and map out the exact critical path for server registration (e.g., controllers, services, database interactions).
    2. Develop in Rust: Implement a functionally equivalent version of this registration logic in Rust.
    3. Integrate: Explore and implement a method for Ruby/Rust integration to "hot-wire" the new Rust module into the RMT application. This may involve using FFI, or libraries like rb-sys or magnus.
    4. Benchmark: Create a benchmarking script (e.g., using k6, ab, or a custom tool) that simulates the high-concurrency registration load from thousands of clients.
    5. Compare & Present: Conduct a comparative performance analysis (requests per second, latency, success/error rates, CPU/memory usage) between the original Ruby path and the new Rust path. The deliverable will be this data and a summary of the findings.

    Resources

    • RMT Source Code (Ruby):
      • https://github.com/SUSE/rmt
    • RMT Documentation:
      • https://documentation.suse.com/sles/15-SP7/html/SLES-all/book-rmt.html
    • Tooling & Stacks:
      • RMT/Ruby development environment (for running the base RMT)
      • Rust development environment (rustup, cargo)
    • Potential Integration Libraries:
      • rb-sys: https://github.com/oxidize-rb/rb-sys
      • Magnus: https://github.com/matsadler/magnus
    • Benchmarking Tools:
      • k6 (https://k6.io/)
      • ab (ApacheBench)