Description
With SUSE Manager, we can build OS Images using KIWI and container images. As we have Edge Image Builder, we want to see if it is possible to use SUSE Manager to build/customize OS Images by integrating Edge Image Builder as well.
Goals
To make the process easier for customers, a single-build pipeline that automatically adds the combustion and artifact files from the EIB process is desirable.
- Kiwi and EIB need to come from a Git Repository.
- Kiwi and EIB need to be running as containers.
- Configuration options for the images used for Kiwi and EIB build.
- X86 and ARM64 Support.
- SUSE Manager 4.3 and 5.X Support.
- SLES 15 SP6 / SL Micro 6.0 and SL Micro 6.1 Support.
Outcome
- Change the Kiwi build process to use Podman with the Kiwi image registry.suse.com/bci/kiwi:10.1.10
- Change the Edge Image Builder to produce a combustion-only ISO
- Extract the contents and write them to a dedicated /OEM partition integrated via Kiwi into the ISO Kiwi creates.
Sources and PRs
- https://github.com/Martin-Weiss/kiwi-image-micro-gpu-60
- https://github.com/suse-edge/edge-image-builder/pull/618
- https://github.com/uyuni-project/uyuni/pull/9507
This project is part of:
Hack Week 24
Activity
Comments
-
about 1 year ago by joachimwerner | Reply
I'm planning to join this project. Some early thoughts and personal perspective:
- I'm mostly working on an Arm Mac, so I'll be able to validate whether all bits and pieces are "Mac-safe" and "aarch64-safe".
- Linux physical machines/VMs vs. containers: Currently, the SUSE Manager KIWI and Dockerfile build jobs are running on a Salt-enabled Linux instance (physical or virtual). EIB (and soon KIWI) are running in a container that can be managed with podman (or potentially Kubernetes). So I see several separate "sub-goals" we could address with this project:
- Keep the current paradigm and "just" create a build state that uses podman on a Linux system to do the EIB build
- Create a new type of container just (podman) and/or Kubernetes host build "server" that would allow running all kinds of containerised jobs through SUSE Manager (including the EIB and soon KIWI build jobs).
- Look into chaining jobs as an advanced goal (important for use cases where you first want to build a base image using KIWI and then customise that image in an EIB "2nd stage").
- Potentially automating build chains based on triggers like "new/updated package was added to repo" (but that could soon lead to re-inventing OBS or so )
- At least for pilot/labs scenarios, I'd love to see the build jobs running on the same podman-enabled host as the SUSE Manager Server instance. Maybe not recommended for production, but would make demos/training labs much easier to set up.
- I'm mostly working on an Arm Mac, so I'll be able to validate whether all bits and pieces are "Mac-safe" and "aarch64-safe".
- I'm mostly working on an Arm Mac, so I'll be able to validate whether all bits and pieces are "Mac-safe" and "aarch64-safe".
- Linux physical machines/VMs vs. containers: Currently, the SUSE Manager KIWI and Dockerfile build jobs are running on a Salt-enabled Linux instance (physical or virtual). EIB (and soon KIWI) are running in a container that can be managed with podman (or potentially Kubernetes). So I see several separate "sub-goals" we could address with this project:
- Keep the current paradigm and "just" create a build state that uses podman on a Linux system to do the EIB build
- Create a new type of container just (podman) and/or Kubernetes host build "server" that would allow running all kinds of containerised jobs through SUSE Manager (including the EIB and soon KIWI build jobs).
- Look into chaining jobs as an advanced goal (important for use cases where you first want to build a base image using KIWI and then customise that image in an EIB "2nd stage").
- Potentially automating build chains based on triggers like "new/updated package was added to repo" (but that could soon lead to re-inventing OBS or so )
- At least for pilot/labs scenarios, I'd love to see the build jobs running on the same podman-enabled host as the SUSE Manager Server instance. Maybe not recommended for production, but would make demos/training labs much easier to set up.
-
about 1 year ago by joachimwerner | Reply
We might need someone with Java skills for the UI part. I've had a first look at the code, and the current UI/business logic implementation is hardcore Java.
Reply to joachimwerner
I'm planning to join this project. Some early thoughts and personal perspective:
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
SUSE Edge Image Builder MCP by eminguez
Description
Based on my other hackweek project, SUSE Edge Image Builder's Json Schema I would like to build also a MCP to be able to generate EIB config files the AI way.
Realistically I don't think I'll be able to have something consumable at the end of this hackweek but at least I would like to start exploring MCPs, the difference between an API and MCP, etc.
Goals
- Familiarize myself with MCPs
- Unrealistic: Have an MCP that can generate an EIB config file
Resources
Set Uyuni to manage edge clusters at scale by RDiasMateus
Description
Prepare a Poc on how to use MLM to manage edge clusters. Those cluster are normally equal across each location, and we have a large number of them.
The goal is to produce a set of sets/best practices/scripts to help users manage this kind of setup.
Goals
step 1: Manual set-up
Goal: Have a running application in k3s and be able to update it using System Update Controler (SUC)
- Deploy Micro 6.2 machine
Deploy k3s - single node
- https://docs.k3s.io/quick-start
Build/find a simple web application (static page)
- Build/find a helmchart to deploy the application
Deploy the application on the k3s cluster
Install App updates through helm update
Install OS updates using MLM
step 2: Automate day 1
Goal: Trigger the application deployment and update from MLM
- Salt states For application (with static data)
- Deploy the application helmchart, if not present
- install app updates through helmchart parameters
- Link it to GIT
- Define how to link the state to the machines (based in some pillar data? Using configuration channels by importing the state? Naming convention?)
- Use git update to trigger helmchart app update
- Recurrent state applying configuration channel?
step 3: Multi-node cluster
Goal: Use SUC to update a multi-node cluster.
- Create a multi-node cluster
- Deploy application
- call the helm update/install only on control plane?
- Install App updates through helm update
- Prepare a SUC for OS update (k3s also? How?)
- https://github.com/rancher/system-upgrade-controller
- https://documentation.suse.com/cloudnative/k3s/latest/en/upgrades/automated.html
- Update/deploy the SUC?
- Update/deploy the SUC CRD with the update procedure
SUSE Edge Image Builder json schema by eminguez
Description
Current SUSE Edge Image Builder tool doesn't provide a json schema (yes, I know EIB uses yaml but it seems JSON Schema can be used to validate YAML documents yay!) that defines the configuration file syntax, values, etc.
Having a json schema will make integrations straightforward, as once the json schema is in place, it can be used as the interface for other tools to consume and generate EIB definition files (like TUI wizards, web UIs, etc.)
I'll make use of AI tools for this so I'd learn more about vibe coding, agents, etc.
Goals
- Learn about json schemas
- Try to implement something that can take the EIB source code and output an initial json schema definition
- Create a PR for EIB to be adopted
- Learn more about AI tools and how those can help on similar projects.
Resources
- json-schema.org
- suse-edge/edge-image-builder
- Any AI tool that can help me!