Daniel Black

A user reports a bug. Its hardware/kernel/data specific. Is it fixed already? How do we get a debug container to the user to use and get meaningful results back?

MariaDB did this with quay.io/mariadb-foundation/mariadb-devel as the continuously released, in progress latest version of release series. Preview features are also provided here.

Also created are quay.io/mariadb-foundation/mariadb-debug containers that include debuginfo packages. The mariadb-debug containers needed to include a range of tools and instructions to make it easy for the users and the developers to bridge their divide for an enhanced bug fixing process.

Containers can also be used to transport a userspace workload to kernel developers to assist improving/fixing kernel features.

For users wanting to help with bug reporting, or for other communities wanting to replicate the concept, a number of really simple things can help this process along significantly.

Using baremetal and user level segregation, we can use systemd multi-instance to provide MariaDB as on demand PaaS, where every user gets their own configuration.

This talk will show you what this looks like from a user and system maintainer perspective.

With containers as all the rage, and the perceived default way of doing things, lets take a look at another approach of PaaS. Systemd as a service manager provides significant functionality on delivering multiple similar services in a managed way, so why not MariaDB PaaS?

So with a few configuration changes from a default MariaDB install, let's show what a per user database instances looks like. Adding socket activation to mix and see "serverless" capability before it came fad with Kubernetes.

On top of that, a brief look at abstract sockets that have been in MariaDB for while and what they could look like in a PaaS environment.