Customers are using complex storage stacks such as LVM over dm-crypt over MD RAID over multipath over iSCSI and FC with LOTs of LUNs, and we're facing problems in that area which are usually very hard to reproduce. It's also hard to guard against regressions.
Being able to quickly and reliably set up VMs with various types of storage / multipath is a key part of testing multipath. It's doable, but cumbersome and has a steep learning curve. I want to create easy-to-understand manual recipes plus scripts that are both easy to understand / customize and deploy.
One of the significant advantages of Wayland is about security, to isolate input/output of every single windows, encourage non-root user running the core process, as well as discouraging root user running any graphical applications. The project wants to have a close look at Wayland trying to address the questions:
- how is wayland exactly integrated in current gnome stack of Tumbleweed/SLE (gnome-shell, mutter)
about 3 years
4 hacker ♥️.
Has no hacker:
Kernel dumps, provided by our customers, are uploaded by Customer Support to ziu.suse.de and shared via NFS to L3 servers at which they're analyzed. This procedure works, but likely has room for improvement.
The goal of the project is to understand the workflows and needs of Customer Support, L3 and engineering (Labs) and to implement a system to automate parts of the workflows.
There is a lot to do in the openSUSE infrastructure land...
So let's start, have a look at https://progress.opensuse.org/, take some tickets and try to resolve them as good as possible. There are also other interesting topics:
Most of design is done still with a embarrassing amount of data. Having released software for decades, we still don't know exactly what module is the most used, what workflows the customers are following, where do customers fail. It is all guesses and opinions.
The idea of this project is to research:
4 hacker ♥️.
Has no hacker:
There seems to be an overall consensus that the ioctl interface used by ethtool is a poor design as it's inflexible, error prone and notoriously hard to extend. It should clearly be replaced by netlink and obsoleted. Unfortunately not much actual work has been done in that direction until this project started.
The project started in Hackweek 16 (fall 2017) and has been worked on since, both in Hackweek 17-19 and outside. First two parts of kernel implementation are in mainline since 5.6-rc1, first part of userspace implementation (ethtool utility) has been submitted to upstream at the end of Hackweek 19 (2020-02-16).
Primarily to support Hackweek, but also to gain experience for a potential future corporate use, I like to run the open source Jitsi in a SUSE context and within a setup that is close to what SUSE IT is doing.
The service will be built in AWS/EKS within the SUSE E&I space and should be up and running on day 1, but will need love during the 5 Hackweek days to