I'm interesting in SLEnkins project and I want to learn it a bit. I will try it and know how it works and how to use it.

To say it's a review, it's better to say it's a good way to learn from others. I'll review test scripts in openQA project as much as I can, digest them and learn how to write Perl script more pretty. I'll make some notes for sharing.

Automation tools are our emotional friends. Know each other deeper and improve it, it's a way to be harmonious for our friendship. 1. SLEnkins

Task: - Learn Twopence structure

Metadata project provides testsuites as a service. Slenkins test wants to use metadata but requires two new fields. I will add nodes and incompatible two new fields.

Flatpak (previously known as xdg-app) is a bundle system, based on ostree, to easily make available applications bundle to users. Currently, flatpack is available on openSUSE Tumbleweed but we don't ship any runtime based on openSUSE (freedesktop or GNOME runtime). Also, it could be interesting to generate flatpak bundle directly from OBS, if possible, using either available packages or directly application sourcecode.

I've attempted this several times already and each attempt had different shortcomings. I'm kind of curious about how exactly will I fail this time. And it looks like I haven't failed this time.

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

WEB_PAGES:

<https://slenkins.suse.de>

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Currently, the usual way to communicate with VM instances in the cloud from outside is ssh. This is okay for most uses, but a) does not work when you mess up with the guest's ability to network and b) requires a free floating IP. I wonder if, for qemu/kvm instances, it would be possible to use virtio-serial possibilities : from the guest, it is seen as a serial port, and from the outside, it is seen as a UNIX socket, or as something else. It is fast, as it does not go through virtualization and device drivers.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Goal: I will look during this project for existing tools and test suites Upstream, used by others distros (like 1) Fedora, 2) Arch-Linux, 3) Debian), and try to learn how they test, use their tool, projects.

Once again, the SUSE band is coming together to make music and we're planning a party this time round!!! We have a band name :-)

<p> Supporttools are great and useful utilities to help support and development

Using traditional hardware development tools, apply a Non-uniform Choppy Transformation to a block of ligneous substance. The end result should be a 3D rendering of the Geeko glyph.

QA uses a dashboard (SUSE internal: http://qa.suse.de/dashboard/ ) to provide an overview of various data to assess the quality of a product. The project is about improving the available data points and the usability for users outside of QA department.

Add support to build snappy images in OBS. This means we need to parse snapcraft.yaml build description for dependencies, prepare data from remote resources and handle the build. ===Current State===

https://github.com/viccuad/gomoduino Gomoduino

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

We all pant for customer data. Which hardware do customers run ? Which packages are installed ? Which services are running ? etc. pp. A lot of this data is in the supportconfig. But this is neither collected, nor centralized, not easily accessible.

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

github https://github.com/okirch/susetest

I want to learn JavaScript or CoffeeScript and how to write Gnome 3 extensions. I think that the right task for learning JS/CS could be work on extension for our wicked network manager because I miss some NetworkManager style plugin. Very basic extension for wicked should contains following:<br>

I want to learn JavaScript or CoffeeScript and how to write Gnome 3 extensions. I think that the right task for learning JS/CS could be work on extension for our wicked network manager because I miss some NetworkManager style plugin. Very basic extension for wicked should contains following:<br>

I want to create a basic web dashboard for Jenkins view with help of Jenkins XML API , Pharo, Seaside and Bootstrap. The biggest benefit for me would be if I can learn how to handle with Classes and its instances containing data from Jenkins in pure object programming language. My goal is to display overall status of the collections in form of progress bars (as openQA does) with info about failed and succeeded slenkins-testcases. Collection view (eg. https://slenkins.suse.de/jenkins/view/Collections-review/) in Jenkins contains list of current SLES builds and each collection has subprojects containing slenkins-testsuites triggered by Jenkins CI for this SLES build.

I want to create a basic web dashboard for Jenkins view with help of Jenkins XML API , Pharo, Seaside and Bootstrap. The biggest benefit for me would be if I can learn how to handle with Classes and its instances containing data from Jenkins in pure object programming language. My goal is to display overall status of the collections in form of progress bars (as openQA does) with info about failed and succeeded slenkins-testcases. Collection view (eg. https://slenkins.suse.de/jenkins/view/Collections-review/) in Jenkins contains list of current SLES builds and each collection has subprojects containing slenkins-testsuites triggered by Jenkins CI for this SLES build.

I want to create a basic web dashboard for Jenkins view with help of Jenkins XML API , Pharo, Seaside and Bootstrap. The biggest benefit for me would be if I can learn how to handle with Classes and its instances containing data from Jenkins in pure object programming language. My goal is to display overall status of the collections in form of progress bars (as openQA does) with info about failed and succeeded slenkins-testcases. Collection view (eg. https://slenkins.suse.de/jenkins/view/Collections-review/) in Jenkins contains list of current SLES builds and each collection has subprojects containing slenkins-testsuites triggered by Jenkins CI for this SLES build.

I want to create a basic web dashboard for Jenkins view with help of Jenkins XML API , Pharo, Seaside and Bootstrap. The biggest benefit for me would be if I can learn how to handle with Classes and its instances containing data from Jenkins in pure object programming language. My goal is to display overall status of the collections in form of progress bars (as openQA does) with info about failed and succeeded slenkins-testcases. Collection view (eg. https://slenkins.suse.de/jenkins/view/Collections-review/) in Jenkins contains list of current SLES builds and each collection has subprojects containing slenkins-testsuites triggered by Jenkins CI for this SLES build.

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

gitbot

https://github.com/MalloZup/gitbot

there is a small security, data manipulation bug on the hackweek-tool. You can try to find it, i will then post it at the end of the hackweek

there is a small security, data manipulation bug on the hackweek-tool. You can try to find it, i will then post it at the end of the hackweek

there is a small security, data manipulation bug on the hackweek-tool. You can try to find it, i will then post it at the end of the hackweek

Currently we use openQA for the the YaST integration tests. It runs YaST in a VM and controls it via emulating keyboard input. The result is checked by comparing the screenshots. This approach has several disadvantages:

For testing Hawk, we're currently using a Vagrant configuration, and for testing HA releases we've been using a set of scripts originally authored by Antoine Ginies as a Hackweek project. My vague idea is to combine Terraform, Salt and a custom web frontend to make a tool that can be used by us as developers but also for others that want to try Hawk or play around with a cluster, for example for the UX team when testing modifications to the Hawk UI. I would base this on the work done by the SUSE Manager team:

Farfalla, is a bot for analyze cucumber failures on the fly. https://github.com/MalloZup/Farfalla

Websh is: https://github.com/HouzuoGuo/websh

headmore is your fully functional VNC client (viewer + control) launched from command line for your geeky character terminals (Linux VT console, xterm, and more): https://github.com/HouzuoGuo/headmore

It seems that systemd-nspawn, together with machinectl can use qcow2 images directly. This means I could use the images genereted by kiwi to start containers (for development and for running the tests).

https://github.com/MalloZup/go-verdura

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

sumaform is a set of terraform modules to deploy SUSE Manager installations originated in Hackweek 14. One year later, it is used virtually by all SUSE Manager developers daily and in our automated test suites - some consultants and SEs also use it.

Taskotop is a tool to check what taskomatic is currently doing on a SUSE Manager server: it's a command line python tool. The core of the tool is to get some info about jobs that taskomatic is running with a fixed time cycle running some queries and showing results to the shell.

Taskotop is a tool to check what taskomatic is currently doing on a SUSE Manager server: it's a command line python tool. The core of the tool is to get some info about jobs that taskomatic is running with a fixed time cycle running some queries and showing results to the shell.

Taskotop is a tool to check what taskomatic is currently doing on a SUSE Manager server: it's a command line python tool. The core of the tool is to get some info about jobs that taskomatic is running with a fixed time cycle running some queries and showing results to the shell.

Taskotop is a tool to check what taskomatic is currently doing on a SUSE Manager server: it's a command line python tool. The core of the tool is to get some info about jobs that taskomatic is running with a fixed time cycle running some queries and showing results to the shell.

Taskotop is a tool to check what taskomatic is currently doing on a SUSE Manager server: it's a command line python tool. The core of the tool is to get some info about jobs that taskomatic is running with a fixed time cycle running some queries and showing results to the shell.

Elixir is a Ruby-ish dialect of Erlang with meta-programming capabilities, this is my first project using it: pedro . The idea is to create a task manager that would organize tasks (jobs) and manage them in projects. It will be running locally, remotely or both in multi-node setup, will provide CLI, have web UI relying on http and websockets. It makes use of erlang OTP, web framework phoenix that is inspired by rails. Author of elixir and main contributor to phoenix is Jose Valim, he's also the author of devise rubygem and former contributor to rails.

After an internal call for help to take over software.opensuse.org deployment, I spend some time studying the code in order to find out what would it mean to take it over. The main reason was a PR from the community that has not been merged, and deployment depending on internal SUSE employees.

Right now portusctl is a tool which is embedded into the Portus source code. This was done out of simplicity and with the hope that we would share as much code as possible with Portus itself. However: - portusctl got bigger and bigger, and it starts to look like a good candidate for getting it in another repository.

Matrix.org is a project to create a protocol and server implementation to replace IRC. Unlike closed tools like Slack, or even open Slack clones like Rocket.chat, Matrix is not focused on a web-client only, but on the protocol to cover all types of clients (text, desktop, web), it is federated (no single server), and it covers good IRC integration (the public matrix server is even on Freenode), and it adds features that Slack clones have like persistent history, pictures, etc.

Why Knowledge is only useful if it is accessible.

Why Knowledge is only useful if it is accessible.

Are you interested in pairing? Are you wondering whether it is something that would help you and your team members in your current project? Would you like to try it out before you fully commit to such an extreme idea? Then this is your lucky day Sir/Madam! Within the Cloud Foundry project you are expected to pair pretty much every time you are working on something. In the BOSH OpenStack CPI team this isn't the exception, so I've been doing it for the past 15 months. I'd like to transfer some of that experience to you fellow SUSE colleague. We can discuss about the pros and cons that this agile methodology has. For example, there are many misconceptions on how to pair, for once, having the right hardware makes a huge difference. During Hack Week 16 you have the chance to test drive a dual-control workstation (see image) which I believe is one of the biggest differentiators to have a good experience when pairing full time.

There is a lot to do in the openSUSE infrastructure land... So let's start, have a look at https://progress.opensuse.org/, take some tickets and try to resolve them as good as possible. There are also other interesting topics:

New Development In previous hack weeks, the first few days ended up being wasted on just getting it working. I'm pleased to share that the code quality has improved dramatically since the last hack week and there are now extensive test cases for both unit testing and testing against real vmcores, and we'll use both mypy and pylint (if installed) to perform static analysis. Packages for those are available in openSUSE or as part of the crash-python OBS repo for SLE15. It has been tested with kernels from 3.0 to 5.1.

There are vastly different syntaxes being used by Linux softwares nowadays - Apache, Bind, NTP, Postfix, just to name a few. It is a very tedious task to implement comprehensive parser for every single configuration file, and even more difficult to produce configuration text (file content) from parsed syntax tree. The project tackles those difficulties by presenting an implementation of a universal parser that is capable of:

In the previous hackweek (14), the following objectives from project "A generic mechanism for analysing and manipulating diverse software configuration files" were worked on: <pre>

We started the SUSE Musician's Space several Hackweeks ago, out of which we spawned the SUSE band, now known as SUSE LOUD. Since there are a lot of musicians in SUSE, not all rock musicians, we decided to see whether we could get some other music projects off the ground during this Hackweek.

Laitos is an open source project written in go, it emphasizes simplicity of maintenance and delivers a complete suite of web, DNS, and mail servers to host a personal web server. Beyond the suite of servers, laitos software hooks into numerous API platforms, that altogether enable user access to Internet features (such as Facebook, Twitter, emails) via alternative communication infrastructures such as telephone (PSTN), SMS, and satellite terminals. For added fun, laitos software enables nostalgic computer systems (such as Windows 98 and DOS) to access modern web by rendering web sites on laitos server, and provides web page interactions via text commands and screenshots.

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:

There is a couple of libraries available for asynchronous and non-blocking processing of HTTP requests (in Java) that can be used to avoid having threads waiting for responses in request intensive applications, for example: - Apache HttpAsyncClient

The idea is to create a bootable medium (eg. pendrive) that allows: * Selection of either SLES, Leap or Tumbleweed.

The idea is getting a general knowledge of how QT Linguist works, and help FET with some translations. FET is a timetable creator, that is available for openSUSE at https://en.opensuse.org/FET, and allows a user to create a timetable, usually for educational institutions, with a lot of different available constraints.

• easy to use commandline tool to generate CA Certificates and Server Certificates
• package the certificates in RPMs for easy deployment

In our team, we currently manually deploy our Terraform code (namely, the SUSE Registry at registry.suse.com) from our own PCs. This is error prone, as it would be very easy to override something by mistake. I want to create the appropriate .gitlab-ci.yml file that will:

Let's use the Hackweek to improve Ruby, the programming language I use every day. It is while using a language when you can realised that things that need/can to be improved, so there are many things that only Ruby developers can raise up. Also, getting involved in the development of Ruby will help to get a better understanding of how it works. So I will take my ideas/concerns to the Ruby community and implement some of the them in the code of the Ruby core. Ruby features and bugs are tracked in https://bugs.ruby-lang.org/projects/ruby-trunk/issues

The goal is to learn about Kaggle and Machine Learning. Resources:

Let's containerize SUSE Manager! This will open up different (and interesting) scenarios: - From a development perspective: learn about all the components that constitute SUSE Manager

Hackweek is a place for fun and things and also great things and a lot of fun. Some things don't require a reason - they are fun, that's all to it. Here goes a small competition with a lot of fun to it. Find Klaas in the office.

There are customer use cases where sharing information via internet or uploading data somewhere is not acceptable for security reasons: this avoid the usage of some tool like the most famous Google Analytics, and prevent developers from understanding how the web application is used by the customers. I don't want to reinvent the wheel and re-implement a copy of Google Analytics, but getting inspired from it, the goal is to reuse information that we already have to extrapolate an analysis of the WebApp customer usage. I started this project with the aim of learning a programming language where I am not so comfortable yet (python). The purpose of this Hack Week project is to bring this basic tool at a minimal stable and usable state with the purpose of analyze the usage of a WebApp in scenarios where the WebApp is used in an internal network only (offline, disconnected from the internet).

Mottainai - Task/Job/Build Server for everyone!

Written in Golang. You can find the source code on GitHub and docs here.

Running openATTIC and DeepSea on Multiple Distributions

code

https://github.com/MalloZup/foresinc

First part is to support automated builds on git pushes also with gitlab, similar to what we do already with github.com. This means OBS would get notificated in a save way to refetch sources and start build on each commit. Second part is to support automated branching when a pull request gets created. This allows CI similar to travis on pull requests.

I'd like to consider the possibilities for redesigning SUSE documentation. Mark Baker ("Every Page is Page One") says "include it all, filter it afterwards" which is the exact antithesis of what we currently offer. Let's consider how we can move documentation into the future: search driven, user friendly, accessible, and in line with the way our readers use the rest of the internet.

kubeojo in 10 seconds-click-me to visualize-demo-link

code:

i want to spend some day of my hackweek to improve salt-toaster https://github.com/openSUSE/salt-toaster

in https://gohugo.io/ you can easily write custom themes via templates for creation of static websites the theme should be responsive for mobile and offer some configuration options

Right now our concourse instance http://salzbreze.suse.de:8080 runs containerized (via docker-compose) on bare metal We already have a production caasp instance, so we can already move it there

If you are now thinking of Salt-SSH, this is not completely wrong, but also not right. What we are talking about here, is an other Transport for Salt, a replacement for ZeroMQ.

Why?

Currently Salt is using supportconfig utility alongside with the SUSE Manager installation. Every single bugreport for Salt, that contains its logs are always useless that regard. It might work for SUSE Manager, but for Salt it doesn't. And even after asking user to switch the cluster into a debug mode or even trace mode, it is still far away from being useful enough, so the supporter don't need to dance with the tambourine around the fire, guessing what ghost just munged what component. What if we can reuse Salt's internal tooling and develop some more tools that will not just grab logs/sysinfo from what is already there, but also get much more data, "x-ray" minions, turn them into a debug mode, collect right data, perform tests realtime etc?

Develop a proof of concept frontend based on React and Material-UI as an alternative to the JSP/Struts based frontend currently available.

Abstract:

• Cloud hosted applications are now composed of many microservices often deployed in containers. When things go wrong, are slow, or just not understood, where can we turn?
  

The goal of Project MySelf is to build a system to collect data about yourself in a safe and private way, so that you control your data and you can decide what happens with it. Read more

Writing code is wonderful, but it gets its real value, when it's released and shipped to the world. You know the mantra: "Release early, release often". Releasing code is not hard, but it involves a lot of details, and you want to get them right, because a release is this public statement "Hey, it's done, it works, you can use it." and you can't take a release back, once it's out there. To help with releases there are tons of release scripts which try to automate things. But they usually are quite fragile in case something goes wrong and a pain to test and maintain.

The idea is about an easy way to allow users to make upgrades (e.g.: changing from one major version like 15.0 to version 15.1) using a GUI and as easy as they can in Ubuntu. Something like a notification with a button to perform the upgrade with just one-click, instead of having to deal with the terminal, that frights some new users and gives them the sensation of an outdated system.

Yes this project is yet another project for creating a Suse Manager clone. The motivation for that comes mainly from my need for a simple suse manager that i can easily run at home without the massive overhead involved in suse manager setup. Also since i mainly need to manage opensuse machines most of which are tumbleweed, suse managers repository model does not really work well in that case.

https://github.com/cornelius/yes_ship_it i was really curious about this project but i never had the time to use it.

I promised to start this project way earlier, but I think Hackweek will be a great time to make a start. The project once was called $BABELFISH, later "Rumsfeld", to honor the creator of the "Unknown unknowns" meme, now it's name is Maxfeld.

Can we improve the remote hackweek experience for remote or non NUE people at SUSE? Feel free to discuss and share ideas.

"salt-toaster" allows you to test multiple Salt package flavors across different operating systems via Docker containers. This project is heavily used on the SUSE Manager team to hardening the Salt package that is shipped on the openSUSE/SLE distributions. Link to GitHub repository The "salt-toaster" execution is divided on different steps (image building, container spinning, salt key acceptance, tests execution, etc) but currently we only get the global results for the entire testsuite execution.

learn both and be awesome

When we started brain storming a project for hack week, one of the floated ideas was to remake the 1983 film WarGames, and for lack of available space, a local lot with storage units was proposed. Over the course of the following years, while we planned, we realized that this whole idea would not be the most feasible, but it still felt like we were onto something. Eventually, we settled with keeping the name and changing the scope.

I would like to learn Elixir, I plan to do some tutorial and look into books. I if I have time also start with Phoenix the framework for Elixir :smile:

The goal of this project is two fold. The first is to better learn and understand why Kubernetes might do something in the way that it does (especially in the control plane)

Rationale:

cosmic-river aims distributed Event-Driven workflows as generic, composable tool

https://github.com/dmulder/phylogen As part of a graduate project I created the phylogen script, which combines the ASTRAL and IQTREE analysis tools into one iterative approach to finding the highest bootstrap score tree for various species of Mayflies. At the completion of the project, there was some work left undone, and I had a few ideas on how to improve the average bootstrap score of the final tree.

This hackweek I will focus on improving my drawing/painting skills. I will do either some portrait for people I know at SUSE and this could be used as Github profiles or do something related to Linux/SUSE chameleon etc. ( without any precise goal).

Although CNCF projects are almost exclusively related to Linux containers, some ideas, like wrapping all the services into network proxies to create a distributed data-plane and enable true observability, could perhaps be explored for some kind of backport in complex legacy distributed systems, like... say... S4/HANA?! I don't even know if this is feasible, but trying won't hurt... just stand at a safe distance from the cluster!

Deploy Uyuni as an app from the Rancher marketplace - or install via Helm on any Kubernetes cluster, on any OS, or any Public Cloud.

The dream