As you know, SUSE acquired Openattic last year, which is a great storage management system. I want to learn and use openattic during this hack week.

SUSE has lots of information in a jungle of tools within the company network. We want to create a platform to extract and refine (distil) the available information and display it in a meaningful manner. The overarching goal is to make available data more accessible. The initial idea sparked in a Knowledge management workshop for the SUSE Documentation Team. A first, refined version was presented as OpenDoc at openSUSE Conference 2016

[Description] I'd like to devote efforts to get the main IO paths of linux network stack from the source codes and related details, such as kernel network initialization/configurations/monitoring/analyzing issues/network traffic scenarios/workloads generating tools/firewall policies, etc.

There are several popular ways of controlling home automation with voice today. Amazon Echo and Google Home both allow users to control lights, speakers, etc. with a simple voice command. For this project, I want to replicate some of the simple voice commands supported by projects like those, but in a way that does all processing from within the local network, and doesn't upload any voice clips to a server outside the home. There's something that feels a little uncomfortable about Amazon or Google having the ability to listen in on all conversations, so I'm trying to eliminate that while still being able to turn my lights on or off by voice.

yast2-storage-ng is a reimplementation of the YaST storage module (yast2-storage) based on the also reimplemented library for storage manager

After joined Gary's BCC workshop a few days ago. The BCC is interesting to me, so I'd like to look into it. - Go through the tutorial. https://github.com/iovisor/bcc/blob/master/docs/tutorialbccpython_developer.md

Since eBPF was introduced into linux kernel, the eBPF verifier keeps the eBPF programs from any wrong-doing. I would like to look into the verifier and see if it's possible to extend the check to avoid reading any sensitive data in the memory.

Parametrizable formulas is a normal salt module plus some metadata in order to interactively parametrize them. The metadata is used to automatically generate forms that are then injected as pillar data. See original Hackweek project, SUSE Manager support for formulas blog article and its (internal for now) docs.

There is a number of possible improvements to the architecture of SUSE Manager / Salt integration that should be investigated in order to improve the reliability and scalability of the backend: 1. Actions are currently scheduled in the minions using the schedule module of Salt. This brings problems with reliability as for instance a minion can be down at the specified schedule time which leads to actions not being executed. Scalability can be an issue as actions being scheduled for many minions might return results to the server at the same time. Instead it might be better to keep control over scheduled actions on the server to allow batching of actions as well as downtimes of minions or even the server. There is a work in progress branch to get started.

The purpose of this project is to implement an Android application which shows some images (or dice) which you must use to create a short story. The requirements and desired features for the app are:

OpenStack is, undoubtedly, a really huge ecosystem of cooperative services. Rally is a benchmarking tool that answers the question: “How does OpenStack work at scale?”. To make this possible, Rally automates and unifies multi-node OpenStack deployment, cloud verification, benchmarking & profiling. Rally does it in a pluggable way, making it possible to check whether OpenStack is going to work well on, say, a 1k-servers installation under high load. Thus it can be used as a basic tool for an OpenStack CI/CD system that would continuously improve its SLA, performance, and stability.

I would like to learn more about ARM/AArch64 emulation in QEMU, especially the boot process and different board emulation. Goals:

Lay out a mock version of an existing SUSE R&D process in JIRA. The process should have a reasonable amount of complexity, like

terraform-provider-libvirt supports CoreOS ignition file/content, which end rendered as kernel command line options (the provider does some nice stuff like allowing you to pass the json content and it will take care of putting it into a temporary file). The idea is to:

froxlor Server Management Panel create and start a push request upstream the openSUSE Leap 42.1 configuration tab

The idea is to produce a standalone, independent tool to save and restore windows positions and sizes, analogous to a similar feature in KDE desktop. This would be handy in various lightweight desktop enviroments.

LVM support for Guix System Distribution

With GNU Guix 0.8.1 and it's distribution there is still lack of LVM support. As I'm probably the only user of LVM, I need to hack support into initrd myself.

Create a openSUSE 13.2 Live CD. As enlightenment doesn't fit on the standard openSUSE CD I'd like to create a Image with it.

posixovl is a FUSE based successor of the old UMSDOS. It has a goal to provide POSIX file system functionality on top of vfat. Its code is nice and well written, but its feature set is not complete yet. It just supports: POSIX modes and user/group, hard and symbolic links, device nodes and named pipes. Much more can be done:

open-sTeam is a platform for cooperative work and cooperative learning developed at the university of paderborn in germany. the platform is being used at http://societyserver.org/ and is being developed further.

• Enlightenment already has some minimal openQA tests but more can be written.
• A extended test Setup using extra repositorys in order to run tests on upstream pre release tarballs and potentially "Nightly/Weekly" builds.