a project by ldragon
Project Description
I recently used melange and apko to build a from scratch image. The result was a set of auditable and easy to use container and apk repository. The toolkit reduces the work need to make from scratch images with minimal work on the actual docker container(which can be quite painful if you've tried making a from scratch image on your own).
The end goal would be to produce 2 utilities. 1. A utility that can build rpms from yaml thus simplifying the rpm building process. This would not aim to replace the entire rpm spec but rather be a subset of functionality and will not include macros for now. The counterpart to this utility would another utility to produce a container image including a minimal set of dependencies from the opensuse repos.
As for the language used for the project, I believe rust will be a good choice, it provides enough flexibility along with a large collection of utilities we can use for this including but not limited to, rpm, oci-spec-rs along with compile time checks to speed up the development process
Goals for this Hackweek
The goals for this hackweek for the rpm utility are the following: 1. produce a signing keypair for packages 2. run a set of commands to produce a binary/lib that can be copied to a directory that will be converted to a rpm 3. output a rpm 4. make a rpm repository that can be used by the container utility
The goals for the container utility are the following: 1. build a container from a repository 2. output the container as a tarball 3. publish the container to a repo
Resources
This project is part of:
Hack Week 23
Activity
Comments
-
almost 2 years ago by ldragon | Reply
@tschmitz and I are working on this together rpmo rpmo is what our tool to produce rpms from yamls is called. As of writing we are able to produce a build env for rpms and download the source(s). What is left is running a pipeline to build everything and finally producing a rpm rpm2container rpm2container should produce a minimal rootfs and turn it into a container using rpms. Currently it is able to produce a rootfs. Todo is generating a config.json to create a bundle to produce a tar ball which can be loaded by podman and executed.
Under the hood both projects use the tumbleweed container via podman to avoid utilizing host tools and remain cross distro compatible. We did evaluate using bwrap but we needed to use the host for zypper using bind mounts and symlinks however the container already provides the environment we require to bootstrap a build env
-
-
almost 2 years ago by ldragon | Reply
at last rpm2container can also produce containers. Leading to the end of this POC. for future folks picking this up, here's a list of things you will want to add to both projects.
rpmo:
it should output a directory complete with a .repo file and other bits needed to make it a valid repo for zypper
support for sources other than archives(eg git or the current directory) and support for local source(eg patches)
auto dynamic linking resolution. rpmo can only generate a rpm with a set of predefined dependencies. it should be possible to do elf parsing and determine sonames the binary is linked to and report them.
signing. Currently rpmo outputs non-signed rpms and the build env explicitly disabled gpg checks both should be resolved
reproducibility. it does work in a hack way. should be made more reliable
rpm2container:
don't skip gpg checks
sbom generation
pushing image to a remote
more on the fly generation of json used in the container.
along with these both should be made to be arch independent. many vars are hardcoded to the compiled arch. this should be changed and both should support building for non-native arches. Overall as a proof of concept I'm proud of how far in a week I managed to come, and how much i got working
Similar Projects
Technical talks at universities by agamez
Description
This project aims to empower the next generation of tech professionals by offering hands-on workshops on containerization and Kubernetes, with a strong focus on open-source technologies. By providing practical experience with these cutting-edge tools and fostering a deep understanding of open-source principles, we aim to bridge the gap between academia and industry.
For now, the scope is limited to Spanish universities, since we already have the contacts and have started some conversations.
Goals
- Technical Skill Development: equip students with the fundamental knowledge and skills to build, deploy, and manage containerized applications using open-source tools like Kubernetes.
- Open-Source Mindset: foster a passion for open-source software, encouraging students to contribute to open-source projects and collaborate with the global developer community.
- Career Readiness: prepare students for industry-relevant roles by exposing them to real-world use cases, best practices, and open-source in companies.
Resources
- Instructors: experienced open-source professionals with deep knowledge of containerization and Kubernetes.
- SUSE Expertise: leverage SUSE's expertise in open-source technologies to provide insights into industry trends and best practices.
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.
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)
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
opensuse haskell package gen project