Right now, every time a new team wants a new room in our Jangouts instance, they have to ping me and I have to manually create the room. That means: * Adding some lines to the corresponding config file

This project is about using Salt SSH for managing systems without the need of an additional agent to be installed (besides sshd). With the SSH protocol the connection is initiated by the management server, thus Salt SSH can be used to even manage systems that are located outside of company firewalls, i.e. machines that cannot access a salt-master due to firewall restrictions. In order to still be able to access resources inside a company network though it would be very helpful if the salt-ssh command supported remote port forwarding (as with the -R parameter of the ssh command) for tunneling other traffic through the existing ssh connection, for instance a package manager might want to install packages from a company internal RPM repository. A patch was therefore contributed to Salt SSH in order to enable this feature (merged into develop):

What is Qubes OS

Qubes OS is an operating system based on Linux with security in mind.

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

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.

See https://github.com/viccuad/salt-configs . The idea is to apply the Puppet code pattern to create salt config files to

The SLE15 development model follows the Factory First policy, where all submissions need to go first to openSUSE:Factory and then to SLE15 repos. This way more bugs are fixed, less patches get lost, less backporting is happening etc. Our openSUSE infrastructure is using salt for configuration management. This was working fine, but suddenly we had to split the openSUSE from the SUSE-DMZ services into separate VLANs, thus the salt codebase had to be split as well. The code itself is mostly formulas and quite similar states between the two set of services though. The only real difference was in the pillars, and even there there was a lot of duplication.

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

Salt – The most intelligent, powerful and flexible open source software for remote execution, configuration automation, cloud control and event-driven orchestration The goal of the project is to bring its power into QAM, improving efficacy of work and possibly replacing other tools, where Salt could perform the task more naturally.

[CaaS] [CAP] Work on a long term solution for L3 team to easily reproduce customer's issues I had previously cobbled up a "one script CaaS2 installer":

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

What is Brine?

The salt-toaster (https://github.com/openSUSE/salt-toaster) is a tool created and developed by SUSE employees that we've been using for testing Salt since few years ago. This tool uses pytest in combination with Docker containers to allow testing the multiple versions of the Salt codebase and as well as Salt packages across multiple distributions.

At SUSE we've implemented a module on Salt called ansiblegate which allows to run and manage your Ansible clusters using Salt. This a very powerful module that bring lot of value to Salt when the users are planning on migrating or starting to use Salt and they already have an existing Ansible infrastructure.

My goal is build on Alberto's work on "yomi" and the new Salt-based virtualization management features that Cedric has contributed, then combine them with a Redfish prototype to do the following from one (ideally idempotent) Salt state (orchestration state if required): * mount the installation media via Redfish

Salt is moving towards a plugable architecture using POP and Idem. This project is about experimenting with those new concepts by applying them to a real life case: the virt execution and state modules. The goals of this project are:

Mash is a Python based CI/CD pipeline for automated testing and publishing of public cloud images. Currently the production and development deployment for the package is inconsistent, slow and manual. This is a barrier to rapid development, deployment and testing. It also means the development workflow is different than production. This can lead to production issues which were not seen during development. In order to modernize the Mash workflow I plan to spend the week digging into a plethora of tools to first learn then build out a new workflow. The goal is to simplify deployment by choosing tools that provide consistency, modularity and repeatability. By leveraging the best tools available we can harden the code and accelerate the release cycle.

There is a number of annoyances and pending improvements when working with the Salt Formula for provisioning Prometheus Exporters in Uyuni: - Fix issue with cleanup in case the monitoring entitlement is removed.

I'll continue the effort I started at last Hackweek to support Windows clients in Uyuni/SUSE Manager using Salt. When this is done, SUSE Manager would act as a WSUS server to Windows clients. https://hackweek.suse.com/20/projects/suse-manager-windows-client-support

Project Description

The idea of this project is to produce some short videos/screencasts, maximum 5 minutes, where you show some cool feature from some of our projects/products.

Language Server Protocol (LSP for friends) is used in a number of code editors these days. There are implementations for various languages, but none for Salt States. The idea is to leverage Salt state module to parse edited files to provide completion of the state ids or paths.

Project Description

In case of applying states for a huge number of minions it's very hard to monitor the status of applying the states.

Project Description

Uyuni is the upstream community project from which the very popular SUSE Manager is derived. It uses its own QE test suite wirtten in Cucumber and Ruby. Currently the Uyuni test suite runs with Ruby 2.5.9 which is EOL since 2021. This is because the most current Ruby version for openSUSE Leap 15.4, which the test suite controller runs on, is still Ruby 2.5.9. Updating the Ruby version allows us to modernize the test suite code base and to use more recent Ruby gems that do not support the old Ruby version anymore.

Project Description

Saline is an addition for salt used in SUSE Manager/Uyuni aimed to provide better control and visibility for states deploymend in the large scale environments.

Project Description

Ignition and combustion are the json configuration files used in SLE Micro/Leap Micro/Microos/ALP. These originated in Fedora CoreOS - so it is not distribution-specific.