A supportconfig provides a lot of files and data from the system, but it is often hard to spot the real issue in it. The idea of this project is to get machine-readable output for the supportconfig data and analyze them.
Over the years, our bugzilla database has grown up in size, becoming a very valuable source of truth for most support and development cases; still searching for specific items is quite tricky and the results do not always match the expectations.
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.
Currently, Uyuni(SUSE Manager) offers a product migration feature, but it doesn't support migration from SLE to SLES4SAP. Users are required to run a separate script to perform this migration, which may not be ideal, especially if Uyuni is already installed. Additionally, the script's requirements vary with each service pack.
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).
This project is planned as a collection of random changes to the documentation files in order to rid them of cluttered in the content, outdated comments, inconsistent style (minor issues), unused parameters, duplications, etc.