The openSUSE.org official infrastructure is getting bigger and complicateder, so #microservices and #serverless FTW!
This project will try to finish the ongoing effort to set up k8s and Cloud Foundry in the openSUSE.org infrastructure, using the SUSE products CaaSP and CAP. The end goal would be to have a fully working PaaS environment, ready to accept static pages for starters, eg static.opensuse.org.
P.S. If no native solution for storageclass for our current storage will be found, then a SES installation will also be performed.
#hackweek #susehackweek #hackweek17 #susecz #cz #prague #k8s #kubernetes #cloudfoundry #opensuse #heroes #opensuseheroes #caasp #cap
Looking for hackers with the skills:
k8s kubernetes cloudfoundry opensuse heroes opensuseheroes caasp cap microservices serverless
This project is part of:
Hack Week 17
Activity
Comments
-
over 6 years ago by hennevogel | Reply
hey @agraul would you be willing to help out with the SES part?
-
-
over 6 years ago by tampakrap | Reply
Small status report:
We have working dashboards: - https://caasp-admin.infra.opensuse.org (caasp-admin) - https://k8sdashboard.infra.opensuse.org (kubernetes UI) - https://stratos.infra.opensuse.org (cloudfoundry UI)
On top of that we have plenty of apps deployed internally: - https://hellocf.cf.infra.opensuse.org - https://html5test-caasp.cf.infra.opensuse.org - https://static-caasp.cf.infra.opensuse.org - https://studioexpress-caasp.cf.infra.opensuse.org - https://software-caasp.cf.infra.opensuse.org
... and publicly: - https://hellocf.opensuse.org - https://html5test-caasp.opensuse.org - https://static-caasp.opensuse.org - https://studioexpress-caasp.opensuse.org - https://software-caasp.opensuse.org (this one being the most important achievement, as it required also memcached set up which we managed to do also successfully)
For future steps please visit our Geekops Trello board
-
over 6 years ago by tampakrap | Reply
A write-up at the openSUSE Heroes blog: https://progress.opensuse.org/news/68
Similar Projects
Extending KubeVirtBMC's capability by adding Redfish support by zchang
Description
In Hack Week 23, we delivered a project called KubeBMC (renamed to KubeVirtBMC now), which brings the good old-fashioned IPMI ways to manage virtual machines running on KubeVirt-powered clusters. This opens the possibility of integrating existing bare-metal provisioning solutions like Tinkerbell with virtualized environments. We even received an inquiry about transferring the project to the KubeVirt organization. So, a proposal was filed, which was accepted by the KubeVirt community, and the project was renamed after that. We have many tasks on our to-do list. Some of them are administrative tasks; some are feature-related. One of the most requested features is Redfish support.
Goals
Extend the capability of KubeVirtBMC by adding Redfish support. Currently, the virtbmc component only exposes IPMI endpoints. We need to implement another simulator to expose Redfish endpoints, as we did with the IPMI module. We aim at a basic set of functionalities:
- Power management
- Boot device selection
- Virtual media mount (this one is not so basic
)
Resources
Metrics Server viewer for Kubernetes by bkampen
This project is finished please visit the github repo below for the tool.
Description
Build a CLI tools which can visualize Kubernetes metrics from the metrics-server, so you're able to watch these without installing Prometheus and Grafana on a cluster.
Goals
- Learn more about metrics-server
- Learn more about the inner workings of Kubernetes.
- Learn more about Go
Resources
https://github.com/bvankampen/metrics-viewer
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
Setup Kanidm as OIDC provider on Kubernetes by jkuzilek
Description
I am planning to upgrade my homelab Kubernetes cluster to the next level and need an OIDC provider for my services, including K8s itself.
Goals
- Successfully configure and deploy Kanidm on homelab cluster
- Integrate with K8s auth
- Integrate with other services (Envoy Gateway, Container Registry, future deployment of Forgejo?)
Resources
kubectl clone: Seamlessly Clone Kubernetes Resources Across Multiple Rancher Clusters and Projects by dpunia
Description
kubectl clone is a kubectl plugin that empowers users to clone Kubernetes resources across multiple clusters and projects managed by Rancher. It simplifies the process of duplicating resources from one cluster to another or within different namespaces and projects, with optional on-the-fly modifications. This tool enhances multi-cluster resource management, making it invaluable for environments where Rancher orchestrates numerous Kubernetes clusters.
Goals
- Seamless Multi-Cluster Cloning
- Clone Kubernetes resources across clusters/projects with one command.
- Simplifies management, reduces operational effort.
Resources
Rancher & Kubernetes Docs
- Rancher API, Cluster Management, Kubernetes client libraries.
Development Tools
- Kubectl plugin docs, Go programming resources.
Building and Installing the Plugin
- Set Environment Variables: Export the Rancher URL and API token:
export RANCHER_URL="https://rancher.example.com"
export RANCHER_TOKEN="token-xxxxx:xxxxxxxxxxxxxxxxxxxx"
- Build the Plugin: Compile the Go program:
go build -o kubectl-clone ./pkg/
- Install the Plugin:
Move the executable to a directory in your
PATH
:
mv kubectl-clone /usr/local/bin/
Ensure the file is executable:
chmod +x /usr/local/bin/kubectl-clone
- Verify the Plugin Installation: Test the plugin by running:
kubectl clone --help
You should see the usage information for the kubectl-clone
plugin.
Usage Examples
- Clone a Deployment from One Cluster to Another:
kubectl clone --source-cluster c-abc123 --type deployment --name nginx-deployment --target-cluster c-def456 --new-name nginx-deployment-clone
- Clone a Service into Another Namespace and Modify Labels:
Enlightenment in Leap 16 by simotek
Description
Get the Enlightenment stack + X11 building and running on the Leap 16 codebase.
Goals
- Get enlightenment / terminology compiling for Leap 16
- Test that they are running correctly in a Virtual Machine.
Resources
Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons
Description
We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.
Goals
Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:
git-annex
pandoc
xmonad
cabal-install
Resources
- https://build.opensuse.org/project/show/devel:languages:haskell/
- https://github.com/opensuse-haskell/configuration/
- #discuss-haskell
- https://www.twitch.tv/peti343
YQPkg - Bringing the Single Package Selection Back to Life by shundhammer
tl;dr
Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.
See section "Result" at the bottom for the current status after the hack week.
Current Status
See the development status issue at the GitHub repo.
tl;dr: It's usable now with all the key features.
It does real package installation / removal / update with reasonable user feedback.
The Past and the Present
We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.
You can search packages based on name, description, "requires" or "provides" level, and many more things.
The Future
YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.
Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?
For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.
But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.
The Idea
YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.
For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.
For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.
Preparatory Work: Initializing the Package Subsystem
To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?
Yes, it is: That part is already working:
https://github.com/yast/yast-ycp-ui-bindings/pull/71
Create openSUSE images for Arm/RISC-V boards by avicenzi
Project Description
Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.
Goal for this Hackweek
Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.
Consider generic EFI images where possible, as some boards can hold a bootloader.
Document in the openSUSE Wiki how to flash and use the image for a given board.
Boards that I have around and there are no images:
- Rock 3B
- Nano PC T3 Plus
- Lichee RV D1
- StartFive VisionFive (has some image needs testing)
Hack Week 22
Hack Week 21
Resources
New migration tool for Leap by lkocman
Update
I will call a meeting with other interested people at 11:00 CET https://meet.opensuse.org/migrationtool
Description
SLES 16 plans to have no yast tool in it. Leap 16 might keep some bits, however, we need a new tool for Leap to SLES migration, as this was previously handled by a yast2-migration-sle
Goals
A tool able to migrate Leap 16 to SLES 16, I would like to cover also other scenarios within openSUSE, as in many cases users would have to edit repository files manually.
- Leap -> Leap n+1 (minor and major version updates)
- Leap -> SLES docs
- Leap -> Tumbleweed
- Leap -> Slowroll
- Leap Micro -> Leap Micro n+1 (minor and major version updates)
- Leap Micro -> MicroOS
Hackweek 24 update
Marcela and I were working on the project from Brno coworking as well as finalizing pieces after the hackweek. We've tested several migration scenarios and it works. But it needs further polishing and testing.
Projected was renamed to opensuse-migration-tool and was submitted to devel project https://build.opensuse.org/requests/1227281
Repository
https://github.com/openSUSE/opensuse-migration-tool
Out of scope is any migration to an immutable system. I know Richard already has some tool for that.
Resources
Tracker for yast stack reduction code-o-o/leap/features#173 YaST stack reduction