gitFS supportan idea by jsmeix For certain directories (e.g. his own documents or /etc/) it would be nice to know who changed what and when (e.g. in /etc/) |
Golan no vendora project by rjschwei At present it is our practice to "vendor" all dependencies for a Golang package. This has the advantage that everything is in one nice package and self contained but it has the disadvantage that dependencies are hidden and therefore security issues may slip through the cracks. The idea is to investigate and create automation "go2rpm" that generates a spec file with the necessary "BuildRequires:" such that the dependencies can be broken into golang- packages and we get rid of the implicit dependency inclusion via "vendor". The potential problem is scale, with some golang applications having thousands of dependencies. |
E9s: Epinio TUIa project by ecandino Project DescriptionMany Kubernetes' users are using K9s to manage their clusters from the terminal. To let them enjoy the same experience it would be nice to have an Epinio TUI (terminal ui application) to manage the Epinio resources. |
Create better async hooks for Uyuni state managementa project by Etheryte Project DescriptionCurrently, much of the async code in the frontend parts of Uyuni suffers from susceptibility to out-of-order request issues, race conditions, etc. There are ways we can sidestep them for specific cases, but since it's created more than one L3 at this point it would be nice to address it in a general way. |
Go zip updater: Appending new files to zip archive without decompressing the whole filean invention by StarryWang Project DescriptionCurrently, Golang's |
support git2tar ball packaging as part of the build processan idea by adrianSuSE To have a more efficient upstream packaging support in OBS, I want to implement the following * Support to mirror git/svn/.. trees on source server |
Training Labs Python Port, Liberty Support and OpenSUSE 13.2 supporta project by dguitarbite Porting training labs to Python. This includes re-implementing the host side BASH scripts (which handle VirtualBox and KVM related tasks) to Python. For full details on this please follow training-labs project: git://git.openstack.org/openstack/training-labs.git |
DevOps application for L3 service on researcha project by fanyadan DevOps is hot, and SUSE now is changing that we will not only provide OS and relative products but also online-application-like products e.g. docker application, so L3 service needs to improve as well. |
Graph Visualization of a Cloud Environmentan idea by joadavis This is actually stealing an idea from Mark Harvey - see https://etherpad.nue.suse.com/p/SOC-Community-Of-Practice_2019_06_19 Our SUSE OpenStack Clouds can have complex topologies and settings, so a visualization could help greatly when starting to work on an unfamiliar cloud (like in a support call). |
make "predictable network interface names" more predictablean idea by mkubecek Since the so-called "predictable names" for network interfaces were introduced, the concept and mainly its implementation has been a target of a lot of critique and sometimes even hate. On the other hand, similar idea works reasonably well for block devices. In my opinion, the main reason why "predictable names" reception was not nearly as good as for block devices is the difference in how the implementation works. For block devices, the device name provided by kernel is preserved and other names based on multiple naming schemes (by path, by UUID, by various device identifiers) are created as symlinks so that all of them (including the original kernel one) can be used simultaneously. On the other hand, network interface has only one name and as it is not represented by a file, symlinks cannot be used for aliases. Therefore even if there are multiple naming schemes (e.g. based on BIOS enumeration, bus address etc.), only one of them can be used for each network device and it's rather unpredictable which one is it going to be. Moreover, some of the generated names are rather long, ugly and inconveninent and unlike with block devices, one cannot just ignore them and use a different name (e.g. one provided by kernel). |