Idea is to prepare some advanced template examples for Heat orchestration in OpenStack, which will show: - how HA for VM guests can be used

openSUSE 13.2 is taking shape on ARM, but we need to make sure we smoothen its edges to make an actual release out of it. The goal of this project is to make sure all devices we should run on actually work and that the last few packages necessary for productive use of ARM devices work properly on 13.2.

In order to build a community around crowbar, our cloud installer, we need to get this running on openSUSE as well. So let's find some time to move the packaging of crowbar from the ibs to the obs! In the end, there should be working packages in

After https://hackweek.suse.com/projects/105 the next thing to merge is hermes. Use ActionMailer for events

In https://github.com/SUSE-Cloud/automation/ we already have mkcloud, which can setup a whole SUSE Cloud on a single host for testing. However, it would be cool, if (instead of a single machine) we could use cloud.suse.de with its capability to add extra networks as requested. This can be pretty easy, as much of the mkcloud code is about making libvirt do the right thing

There are a lot of issues in Crowbar due to the legacy of poor internals. This is blocking things quite a bit when it comes to improving Crowbar for adding new features. Let's fix it! So far, 39 pull requests opened!

openQA has a well earned reputation as a 'full system' testing tool, able to test a system end-to-end from the operating system to it's applications on a number of different platforms and architectures, including VM's & Bare Metal. But one area of weakness is it's usefulness as a testing tool for developers or packagers. openQA can easily test a package once it's INSIDE a distribution, but how do you test that package BEFORE submitting it to the distribution?

Metal³ is the idea to support a declarative bare metal cluster management for Kubernates by employing a simplified stand alone version of Ironic.

We should explore if

Build and benchmark some smaller SES clusters (2 - 3 nodes) targetted at edge deployments. Evaluate the performance and configurations.

The idea here is to study and understand how ephemeral storage for containers works and investigate if local storage could be avoided at all and Ceph used instead. Could new storage driver be developed to support Ceph storage:

Investigate possibilities for the distributed builds for Ceph to speed up builds. This task could have 2 scopes.

Since Kubernetes already has a clear path of "in-tree" volume plugin to CSI migration. I would like to understand the concept of CSI with writing a simple driver for Kubernetes. Reference:

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.