Running openATTIC and DeepSea on Multiple Distributions

ABSTRACT

At least a millennia ago, there was this interestingly odd fellow living in a small village in what would one day become the middle of nowhere. No one really knows what this fellow was up to during his days, but we know very well we have zero clue what he was doing during his nights. What is really interesting about this fellow is that he lived in a small village, and the village itself was so remote that it was completely cut-off from the world. The village itself became a self-sustaining cooperative organism, where every single individual contributed some of their to a broader cause: the survival and advancement of their small village.

Even though records found in a given blog's posts points to all the villagers being bound by a single-conscious organism at some point, and eventually being destroyed because one of them got the flu, for most of their existence they were individuals with different (and sometimes very specific) skills who tried to live their lives in the most boring way possible -- why is this relevant? We're not sure, but we are being told we don't need an abstract and we should instead be quite specific on what we add to the projects descriptions, instead of trying to create inspiring (but ultimately pointless) stories about why we need this.

MOTIVATION

In a nutshell, because "this is not nanowrimo", we want to have both openATTIC and DeepSea working on multiple distributions. Some would argue they already work in openSUSE and SLE, so multiple distros amiright??, but come on... -_-'

We need oA and DeepSea to be available in multiple distributions because

  1. we should share the love with the whole wide world; and,
  2. projects without strong, vibrant communities tend to stagnate, and die horrible deaths.

We don't want that. We want every single person in the world to be using openATTIC to manage and monitor Ceph, regardless of their distro affiliation card.

This will necessarily mean making sure oA and DeepSea properly work in at least CentOS and Ubuntu, as most of the Ceph community orbits around those two distributions - which is not a surprise, given Ceph packages were traditionally tested and built for ubuntu, eventually for CentOS.

JOIN US!

We have setup a trello board [1] with tasks pending and currently being worked on, so feel free to take a look! If you'd like to join us, poke us through the hackweek project and lets try to figure out a way to sync up :)

[1] https://trello.com/b/K49DeC9D/hackweek-nov-2017

Looking for hackers with the skills:

openattic deepsea saltstack rpm packaging python

This project is part of:

Hack Week 16

Activity

  • over 7 years ago: dmaiocchi joined this project.
  • over 7 years ago: dmaiocchi liked this project.
  • about 8 years ago: LenzGr added keyword "rpm" to this project.
  • about 8 years ago: LenzGr added keyword "packaging" to this project.
  • about 8 years ago: LenzGr added keyword "python" to this project.
  • about 8 years ago: LenzGr joined this project.
  • about 8 years ago: rimarques joined this project.
  • about 8 years ago: tmelo joined this project.
  • about 8 years ago: rjdias joined this project.
  • about 8 years ago: jluis liked this project.
  • about 8 years ago: jluis added keyword "openattic" to this project.
  • about 8 years ago: jluis added keyword "deepsea" to this project.
  • about 8 years ago: jluis added keyword "saltstack" to this project.
  • about 8 years ago: jluis started this project.
  • about 8 years ago: jluis originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    Ansible to Salt integration by vizhestkov

    Description

    We already have initial integration of Ansible in Salt with the possibility to run playbooks from the salt-master on the salt-minion used as an Ansible Control node.

    In this project I want to check if it possible to make Ansible working on the transport of Salt. Basically run playbooks with Ansible through existing established Salt (ZeroMQ) transport and not using ssh at all.

    Goals

    • [v] Prepare the testing environment with Salt and Ansible installed
    • [v] Discover Ansible codebase to figure out possible ways of integration
    • [v] Create Salt/Uyuni inventory module
    • [v] Make basic modules to work with no using separate ssh connection, but reusing existing Salt connection
    • [v] Test some most basic playbooks

    Resources

    GitHub page

    Video of the demo


    Create a page with all devel:languages:perl packages and their versions by tinita

    Description

    Perl projects now live in git: https://src.opensuse.org/perl

    It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.

    I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta

    But I never had the time to automate this.

    I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).

    Goals

    • Have a script that updates a central repository (e.g. https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run)
    • Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)

    Resources

    Results

    Day 1

    Day 2

    • HTML Page has now links to src.opensuse.org and the date of the last update, plus a short info at the top
    • Code is now 100% covered by tests: https://app.codecov.io/gh/perlpunk/opensuse-perl-meta
    • I used the modern perl class feature, which makes perl classes even nicer and shorter. See example
    • Tests
      • I tried out the mocking feature of the modern Test2::V0 library which provides call tracking. See example
      • I tried out comparing data structures with the new Test2::V0 library. It let's you compare parts of the structure with the like function, which only compares the date that is mentioned in the expected data. example

    Day 3

    • Added various things to the table
      • Dependencies column
      • Show popup with info for cpanspec, patches and dependencies
      • Added last date / commit to the data export.

    Plan: With the added date / commit we can now daily check _ObsPrj for changes and only fetch the data for changed packages.

    Day 4


    Switch software-o-o to store repomd in a database by hennevogel

    Description

    The openSUSE Software portal is a web app to explore binary packages of openSUSE distributions. Kind of like an package manager / app store.

    https://software.opensuse.org/

    This app has been around forever (August 2007) and it's architecture is a bit brittle. It acts as a frontend to the OBS distributions and published binary search APIs, calculates and caches a lot of stuff in memory and needs code changes nearly every openSUSE release to keep up.

    As you can imagine, it's a heavy user of the OBS API, especially when caches are cold.

    Goals

    I want to change the app to cache repomod data in a (postgres) database structure

    • Distributions have many Repositories
    • Repositories have many Packages
    • Packages have many Patches

    The UI workflows will be as following

    • As an admin I setup Distribution and it's repositories
    • As an admin I sync all repositories repomd files into to the database
    • As a user I browse a Distribution by category
    • As a user I search for Package of a Distribution in it's Repositories
    • As a user I extend the search to Package build on OBS for this Distribution

    This has a couple of pro's:

    • Less traffic on the OBS API as the usual Packages are inside the database
    • Easier base to add features to this page. Like comments, ratings, openSUSE specific screenshots etc.
    • Separating the Distribution package search from searching through OBS will hopefully make more clear for newbies that enabling extra repositories is kind of dangerous.

    And one con:

    • You can't search for packages build for foreign distributions with this app anymore (although we could consume their repomd etc. but I doubt we have the audience on an opensuse.org domain...)

    TODO

    • add-emoji Introduce a PG database
    • add-emoji Add clockworkd as scheduler and delayed_job as ActiveJob backend
    • add-emoji Introduce ActiveStorage
    • add-emoji Build initial data model
    • add-emoji Introduce repomd to database sync
      • add-emoji Adapt repomd sync to Leap 16.0 repomod layout changes (single arch, no update repo)
      • add-emoji Make repomd sync idempotent
    • add-emoji Introduce database search
    • add-emoji Setup foreman to run rails s and rake jobs:workoff
    • Adapt UI
      • add-emoji Build Category Browsing
      • add-emoji Build Admin Distribution CRUD interface


    A CLI for Harvester by mohamed.belgaied

    Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI. Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

    Project Description

    Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

    asciicast

    Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

    Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

    Done in previous Hackweeks

    • Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
    • Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

    Goal for this Hackweek

    The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

    Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

    Issue list is here: https://github.com/belgaied2/harvester-cli/issues

    Resources

    The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

    • Testing it and creating issues
    • Documentation
    • Go code improvement

    What you might learn

    Harvester CLI might be interesting to you if you want to learn more about:

    • GitHub Actions
    • Harvester as a SUSE Product
    • Go programming language
    • Kubernetes API
    • Kubevirt API objects (Manipulating VMs and VM Configuration in Kubernetes using Kubevirt)


    openSUSE on ZoL from OpenZFS project by jkohoutek

    Idea is to have SUSE system with OpenZFS as root FS.

    Why ZFS

    Ways in which ZFS is better than BTRFS

    Main goal

    Have OpenZFS as install option in the installer and utilize zedenv Boot Environment Manager for SUSE updates install

    Goals

    • synergy of ZFS with dracut, so snapshots are correctly added to the grub
    • synergy of zedenv with zypper
      • before every update snapshot is created
      • when new kernel or other package which requires reboot is about to be installed, the update will be processed to the new boot environment snapshot and grub configuration changed to boot to this new one
    • integrate Root on ZFS as install option to the YaST
    • configure Kiwi for the ZFS install images

    Completed goals

    • prepare ZFS pool compatible with openSUSE installation ✓
    • install openSUSE with root on ZFS ✓
    • boot to the prepared and installed system ✓

    Current progress

    Resources:


    GHC-9.14 and split Hadrian from GHC build by osukup

    Description

    Prepare openSUSE Tumbleweed project for new GHC Haskell compiler and separate builder (Hadrian) from GHC build

    Goals

    • have GHC-9.14 project with working compiler and if possible filled with packageset
    • have Hadrian in own package built with bootstrap compiler to separate Hadrian bootstrap from ghc bootstrap

    Resources

    devel:languages:haskell

    d:l:h:ghc-9.12.x

    opensuse Haskell rpm macros

    opensuse haskell package gen project


    Improve chore and screen time doc generator script `wochenplaner` by gniebler

    Description

    I wrote a little Python script to generate PDF docs, which can be used to track daily chore completion and screen time usage for several people, with one page per person/week.

    I named this script wochenplaner and have been using it for a few months now.

    It needs some improvements and adjustments in how the screen time should be tracked and how chores are displayed.

    Goals

    • Fix chore field separation lines
    • Change screen time tracking logic from "global" (week-long) to daily subtraction and weekly addition of remainders (more intuitive than current "weekly time budget method)
    • Add logic to fill in chore fields/lines, ideally with pictures, falling back to text.

    Resources

    tbd (Gitlab repo)


    Update M2Crypto by mcepl

    There are couple of projects I work on, which need my attention and putting them to shape:

    Goal for this Hackweek

    • Put M2Crypto into better shape (most issues closed, all pull requests processed)
    • More fun to learn jujutsu
    • Play more with Gemini, how much it help (or not).
    • Perhaps, also (just slightly related), help to fix vis to work with LuaJIT, particularly to make vis-lspc working.


    Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy

    Description

    The Mission: Decentralized & Sovereign Messaging

    FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com

    In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.

    However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.

    Why This Matters

    A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:

    • Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
    • Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
    • Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.

    By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.

    Goals

    As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.

    Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:

    • Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
    • Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
    • Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
    • Allow the use of bind or remote mounted volumes for shared data (/var/vmail, DKIM keys, TLS certs, etc.).
    • Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.

    By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol

    Resources


    Liz - Prompt autocomplete by ftorchia

    Description

    Liz is the Rancher AI assistant for cluster operations.

    Goals

    We want to help users when sending new messages to Liz, by adding an autocomplete feature to complete their requests based on the context.

    Example:

    • User prompt: "Can you show me the list of p"
    • Autocomplete suggestion: "Can you show me the list of p...od in local cluster?"

    Example:

    • User prompt: "Show me the logs of #rancher-"
    • Chat console: It shows a drop-down widget, next to the # character, with the list of available pod names starting with "rancher-".

    Technical Overview

    1. The AI agent should expose a new ws/autocomplete endpoint to proxy autocomplete messages to the LLM.
    2. The UI extension should be able to display prompt suggestions and allow users to apply the autocomplete to the Prompt via keyboard shortcuts.

    Resources

    GitHub repository


    Improvements to osc (especially with regards to the Git workflow) by mcepl

    Description

    There is plenty of hacking on osc, where we could spent some fun time. I would like to see a solution for https://github.com/openSUSE/osc/issues/2006 (which is sufficiently non-serious, that it could be part of HackWeek project).