Contribute to terraform-provider-libvirt by pinvernizzi

Description

The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.

It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.

If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.

Goals

• Get more familiar with Terraform provider development and libvirt bindings in Go
• Solve some issues and/or implement some features
• Get in touch with the community around the project

Resources

• CONTRIBUTING readme
• Go libvirt library in use by the project
• Terraform plugin development
• "Good first issue" list

---

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
3. Package management (install, remove, update...)
4. Patching
5. Applying any basic salt state (including a formula)
6. Salt remote commands
7. Bonus point: Java part for product identification, and monitoring enablement
8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

• If you don't have knowledge about some of the steps: ask the team
• If you still don't know what to do: switch to another distribution and keep testing.

This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

Pending

FUSS

FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

https://fuss.bz.it/

Seems to be a Debian 12 derivative, so adding it could be quite easy.

• [ ] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
• [ ] Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
• [ ] Package management (install, remove, update...)
• [ ] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already)
• [ ] Applying any basic salt state (including a formula)
• [ ] Salt remote commands
• [ ] Bonus point: Java part for product identification, and monitoring enablement

---

terraform-provider-feilong by e_bischoff

Project Description

People need to test operating systems and applications on s390 platform.

Installation from scratch solutions include:

• just deploy and provision manually (with the help of ftpboot script, if you are at SUSE)
• use s3270 terminal emulation (used by openQA people?)
• use LXC from IBM to start CP commands and analyze the results
• use zPXE to do some PXE-alike booting (used by the orthos team?)
• use tessia to install from scratch using autoyast
• use libvirt for s390 to do some nested virtualization on some already deployed z/VM system
• directly install a Linux kernel on a LPAR and use kvm + libvirt from there

Deployment from image solutions include:

• use ICIC web interface (openstack in disguise, contributed by IBM)
• use ICIC from the openstack terraform provider (used by Rancher QA)
• use zvm_ansible to control SMAPI
• connect directly to SMAPI low-level socket interface

IBM Cloud Infrastructure Center (ICIC) harnesses the Feilong API, but you can use Feilong without installing ICIC, provided you set up a "z/VM cloud connector" into one of your VMs following this schema.

What about writing a terraform Feilong provider, just like we have the terraform libvirt provider? That would allow to transparently call Feilong from your main.tf files to deploy and destroy resources on your system/z.

Other Feilong-based solutions include:

• make libvirt Feilong-aware
• simply call Feilong from shell scripts with curl
• use zvmconnector client python library from Feilong
• use zthin part of Feilong to directly command SMAPI.

Goal for Hackweek 23

My final goal is to be able to easily deploy and provision VMs automatically on a z/VM system, in a way that people might enjoy even outside of SUSE.

My technical preference is to write a terraform provider plugin, as it is the approach that involves the least software components for our deployments, while remaining clean, and compatible with our existing development infrastructure.

Goals for Hackweek 24

Feilong provider works and is used internally by SUSE Manager team. Let's push it forward!

• Fix problems with registration on hashicorp providers registry
• Add support for fiberchannel disks
• Finish the U part of CRUD
• Move from private repos to Open Mainframe project
• Anything else as needed

---

SUSE AI Meets the Game Board by moio

Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!

---

AI + Board Games

Board games have long been fertile ground for AI innovation, pushing the boundaries of capabilities such as strategy, adaptability, and real-time decision-making - from Deep Blue's chess mastery to AlphaZero’s domination of Go. Games aren’t just fun: they’re complex, dynamic problems that often mirror real-world challenges, making them interesting from an engineering perspective.

As avid board gamers, aspiring board game designers, and engineers with careers in open source infrastructure, we’re excited to dive into the latest AI techniques first-hand.

Our goal is to develop an all-open-source, all-green AWS-based stack powered by some serious hardware to drive our board game experiments forward!

---

Project Goals

1. Set Up the Stack:

   • Install and configure the TAG and PyTAG frameworks on SUSE Linux Enterprise Base Container Images.
   • Integrate with the SUSE AI stack for GPU-accelerated training on AWS.
   • Validate a sample GPU-accelerated PyTAG workload on SUSE AI.
   • Ensure the setup is entirely repeatable with Terraform and configuration scripts, documenting results along the way.

2. Design and Implement AI Agents:

   • Develop AI agents for the two board games, incorporating Statistical Forward Planning and Deep Reinforcement Learning techniques.
   • Fine-tune model parameters to optimize game-playing performance.
   • Document the advantages and limitations of each technique.

3. Test, Analyze, and Refine:

   • Conduct AI vs. AI and AI vs. human matches to evaluate agent strategies and performance.
   • Record insights, document learning outcomes, and refine models based on real-world gameplay.

---

Technical Stack

• Frameworks: TAG and PyTAG for AI agent development
• Platform: SUSE AI
• Tools: AWS for high-performance GPU acceleration

---

Why This Project Matters

This project not only deepens our understanding of AI techniques by doing but also showcases the power and flexibility of SUSE’s open-source infrastructure for supporting high-level AI projects. By building on an all-open-source stack, we aim to create a pathway for other developers and AI enthusiasts to explore, experiment, and deploy their own innovative projects within the open-source space.

---

Our Motivation

We believe hands-on experimentation is the best teacher.

Combining our engineering backgrounds with our passion for board games, we’ll explore AI in a way that’s both challenging and creatively rewarding. Our ultimate goal? To hack an AI agent that’s as strategic and adaptable as a real human opponent (if not better!) — and to leverage it to design even better games... for humans to play!

---

A CLI for Harvester by mohamed.belgaied

[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # 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

---

Introducing "Bottles": A Proof of Concept for Multi-Version CRD Management in Kubernetes by aruiz

Description

As we delve deeper into the complexities of managing multiple CRD versions within a single Kubernetes cluster, I want to introduce "Bottles" - a proof of concept that aims to address these challenges.

Bottles propose a novel approach to isolating and deploying different CRD versions in a self-contained environment. This would allow for greater flexibility and efficiency in managing diverse workloads.

Goals

• Evaluate Feasibility: determine if this approach is technically viable, as well as identifying possible obstacles and limitations.
• Reuse existing technology: leverage existing products whenever possible, e.g. build on top of Kubewarden as admission controller.
• Focus on Rancher's use case: the ultimate goal is to be able to use this approach to solve Rancher users' needs.

Resources

Core concepts:

• ConfigMaps: Bottles could be defined and configured using ConfigMaps.
• Admission Controller: An admission controller will detect "bootled" CRDs being installed and replace the resource name used to store them.
• Aggregated API Server: By analyzing the author of a request, the aggregated API server will determine the correct bottle and route the request accordingly, making it transparent for the user.

---

CVE portal for SUSE Rancher products by gmacedo

Description

Currently it's a bit difficult for users to quickly see the list of CVEs affecting images in Rancher, RKE2, Harvester and Longhorn releases. Users need to individually look for each CVE in the SUSE CVE database page - https://www.suse.com/security/cve/ . This is not optimal, because those CVE pages are a bit hard to read and contain data for all SLE and BCI products too, making it difficult to easily see only the CVEs affecting the latest release of Rancher, for example. We understand that certain costumers are only looking for CVE data for Rancher and not SLE or BCI.

Goals

The objective is to create a simple to read and navigate page that contains only CVE data related to Rancher, RKE2, Harvester and Longhorn, where it's easy to search by a CVE ID, an image name or a release version. The page should also provide the raw data as an exportable CSV file.

It must be an MVP with the minimal amount of effort/time invested, but still providing great value to our users and saving the wasted time that the Rancher Security team needs to spend by manually sharing such data. It might not be long lived, as it can be replaced in 2-3 years with a better SUSE wide solution.

Resources

• The page must be simple and easy to read.
• The UI/UX must be as straightforward as possible with minimal visual noise.
• The content must be created automatically from the raw data that we already have internally.
• It must be updated automatically on a daily basis and on ad-hoc runs (when needed).
• The CVE status must be aligned with VEX.
• The raw data must be exportable as CSV file.
• Ideally it will be written in Go or pure Shell script with basic HTML and no external dependencies in CSS or JS.

---

Cluster API Provider for Harvester by rcase

Project Description

The Cluster API "infrastructure provider" for Harvester, also named CAPHV, makes it possible to use Harvester with Cluster API. This enables people and organisations to create Kubernetes clusters running on VMs created by Harvester using a declarative spec.

The project has been bootstrapped in HackWeek 23, and its code is available here.

Work done in HackWeek 2023

• Have a early working version of the provider available on Rancher Sandbox : *DONE *
• Demonstrated the created cluster can be imported using Rancher Turtles: DONE
• Stretch goal - demonstrate using the new provider with CAPRKE2: DONE and the templates are available on the repo

Goals for HackWeek 2024

• Add support for ClusterClass
• Add e2e testing
• Add more Unit Tests
• Improve Status Conditions to reflect current state of Infrastructure
• Improve CI (some bugs for release creation)
• Testing with newer Harvester version (v1.3.X and v1.4.X)
• Due to the length and complexity of the templates, maybe package some of them as Helm Charts.
• Other improvement suggestions are welcome!

Resources

Looking for help from anyone interested in Cluster API (CAPI) or who wants to learn more about Harvester.

This will be an infrastructure provider for Cluster API. Some background reading for the CAPI aspect:

• Cluster infrastructure provider contract
• Machine infrastructure provider contract
• Provider implementers guide

---

Integrate Backstage with Rancher Manager by nwmacd

Description

Backstage (backstage.io) is an open-source, CNCF project that allows you to create your own developer portal. There are many plugins for Backstage.

This could be a great compliment to Rancher Manager.

Goals

Learn and experiment with Backstage and look at how this could be integrated with Rancher Manager. Goal is to have some kind of integration completed in this Hack week.

---

Integrate Backstage with Rancher Manager by nwmacd

Description

Backstage (backstage.io) is an open-source, CNCF project that allows you to create your own developer portal. There are many plugins for Backstage.

This could be a great compliment to Rancher Manager.

Goals

Learn and experiment with Backstage and look at how this could be integrated with Rancher Manager. Goal is to have some kind of integration completed in this Hack week.

---

Mammuthus - The NFS-Ganesha inside Kubernetes controller by vcheng

Description

As the user-space NFS provider, the NFS-Ganesha is wieldy use with serval projects. e.g. Longhorn/Rook. We want to create the Kubernetes Controller to make configuring NFS-Ganesha easy. This controller will let users configure NFS-Ganesha through different backends like VFS/CephFS.

Goals

1. Create NFS-Ganesha Package on OBS
2. Create NFS-Ganesha Container Image on OBS
3. Create a Kubernetes controller for NFS-Ganesha and support the VFS configuration on demand.

Resources

NFS-Ganesha

---

A CLI for Harvester by mohamed.belgaied

[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # 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

---

ClusterOps - Easily install and manage your personal kubernetes cluster by andreabenini

Description

ClusterOps is a Kubernetes installer and operator designed to streamline the initial configuration and ongoing maintenance of kubernetes clusters. The focus of this project is primarily on personal or local installations. However, the goal is to expand its use to encompass all installations of Kubernetes for local development purposes.
It simplifies cluster management by automating tasks and providing just one user-friendly YAML-based configuration config.yml.

Overview

• Simplified Configuration: Define your desired cluster state in a simple YAML file, and ClusterOps will handle the rest.
• Automated Setup: Automates initial cluster configuration, including network settings, storage provisioning, special requirements (for example GPUs) and essential components installation.
• Ongoing Maintenance: Performs routine maintenance tasks such as upgrades, security updates, and resource monitoring.
• Extensibility: Easily extend functionality with custom plugins and configurations.
• Self-Healing: Detects and recovers from common cluster issues, ensuring stability, idempotence and reliability. Same operation can be performed multiple times without changing the result.
• Discreet: It works only on what it knows, if you are manually configuring parts of your kubernetes and this configuration does not interfere with it you can happily continue to work on several parts and use this tool only for what is needed.

Features

• distribution and engine independence. Install your favorite kubernetes engine with your package manager, execute one script and you'll have a complete working environment at your disposal.
  
• Basic config approach. One single config.yml file with configuration requirements (add/remove features): human readable, plain and simple. All fancy configs managed automatically (ingress, balancers, services, proxy, ...).
• Local Builtin ContainerHub. The default installation provides a fully configured ContainerHub available locally along with the kubernetes installation. This configuration allows the user to build, upload and deploy custom container images as they were provided from external sources. Internet public sources are still available but local development can be kept in this localhost server. Builtin ClusterOps operator will be fetched from this ContainerHub registry too.
• Kubernetes official dashboard installed as a plugin, others planned too (k9s for example).
• Kubevirt plugin installed and properly configured. Unleash the power of classic virtualization (KVM+QEMU) on top of Kubernetes and manage your entire system from there, libvirtd and virsh libs are required.
• One operator to rule them all. The installation script configures your machine automatically during installation and adds one kubernetes operator to manage your local cluster. From there the operator takes care of the cluster on your behalf.
• Clean installation and removal. Just test it, when you are done just use the same program to uninstall everything without leaving configs (or pods) behind.

Planned features (Wishlist / TODOs)

• Containerized Data Importer (CDI). Persistent storage management add-on for Kubernetes to provide a declarative way of building and importing Virtual Machine Disks on PVCs for

---

Introducing "Bottles": A Proof of Concept for Multi-Version CRD Management in Kubernetes by aruiz

Description

As we delve deeper into the complexities of managing multiple CRD versions within a single Kubernetes cluster, I want to introduce "Bottles" - a proof of concept that aims to address these challenges.

Bottles propose a novel approach to isolating and deploying different CRD versions in a self-contained environment. This would allow for greater flexibility and efficiency in managing diverse workloads.

Goals

• Evaluate Feasibility: determine if this approach is technically viable, as well as identifying possible obstacles and limitations.
• Reuse existing technology: leverage existing products whenever possible, e.g. build on top of Kubewarden as admission controller.
• Focus on Rancher's use case: the ultimate goal is to be able to use this approach to solve Rancher users' needs.

Resources

Core concepts:

• ConfigMaps: Bottles could be defined and configured using ConfigMaps.
• Admission Controller: An admission controller will detect "bootled" CRDs being installed and replace the resource name used to store them.
• Aggregated API Server: By analyzing the author of a request, the aggregated API server will determine the correct bottle and route the request accordingly, making it transparent for the user.

---