gitFS support

an 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/)

Updated about 5 years ago. 1 hackers ♥️. Has no hacker: grab it!

Golan no vendor

a 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.

Updated over 4 years ago. 1 hackers ♥️. 1 follower.

E9s: Epinio TUI

a project by ecandino

Project Description

Many 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.

Updated over 1 year ago. 1 hackers ♥️. 1 follower.

Create better async hooks for Uyuni state management

a project by Etheryte

Project Description

Currently, 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.

Updated 6 months ago. 1 hackers ♥️. 1 follower.

Go zip updater: Appending new files to zip archive without decompressing the whole file

an invention by StarryWang

Project Description

Currently, Golang's archive/zip standard library does not support appending new files to the existing zip archive.

Updated 6 months ago. 1 hackers ♥️. 1 follower.

support git2tar ball packaging as part of the build process

an 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

Updated about 5 years ago. 1 hackers ♥️. Has no hacker: grab it!

Training Labs Python Port, Liberty Support and OpenSUSE 13.2 support

a 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

Updated about 5 years ago. 1 hackers ♥️.

DevOps application for L3 service on research

a 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.
Google has established their DevOps implementation - SRE system, and has maintained long time, I opened this project for researching if DevOps way could be applied on L3 service referring to Google's experience.

Updated over 4 years ago. 1 hackers ♥️.

Graph Visualization of a Cloud Environment

an 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).

Updated almost 5 years ago. 1 hackers ♥️. 1 follower. Has no hacker: grab it!

make "predictable network interface names" more predictable

an 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).

Updated over 4 years ago. 1 hackers ♥️. 2 followers. Has no hacker: grab it!