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!

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

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.

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!

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.

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

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.

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.

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.