Initially, the Agama D-Bus service was written 100% in Ruby. For many things, it relies on YaST, so it makes sense to use the same language. It was great to have something working quickly, but it also had some drawbacks. The main problem is that, as YaST is not thread-safe, we separated the service into different processes (storage, software, localization, etc.). The system became most responsive but at the cost of eating a lot of RAM.

Working remotely has many advantages, but you sometimes lack some infrastructure. Specially if you use several computers or you share space with other SUSE co-workers. We are 3 Susers in Gran Canaria and we plan to share an office. So we have bought a Cubietruck, a tiny device with minimum power consumption, an ARM processor, a SATA interface and a Gigabit ethernet.

Occasionally, new versions of openQA break things. How do you stop that? MORE TESTING!

Project Description

Last time I checked QEMU lacked support for >= z10 processors. Thus one cannot run SLE12 and newer in a virtual machine on non-s390x host. I'd like to improve the situation during Hackweeks.

Often when we test maintenance updates or when we decide to push an update for a package we want to know what that change may cause. Right now it is really difficult to figure out what package depends on a given package.

Project Description

• Create an automated L0-support-like analytics solution for supportconfig data that is tiered across a customer's environment and SUSE environment (similar to a very modular AIOps Edge-Core approach). A pictorial overview of the ecosystem

Deploy Uyuni as an app from the Rancher marketplace - or install via Helm on any Kubernetes cluster, on any OS, or any Public Cloud.