Aim of this project is to create scenarios for manual deployment using limited feature set of mkcloud. Useful for situations when full mkcloud deployment is broken. It would help qam-cloud team a big time. We can reuse the result later in automation.
We recently changed from IRC to Rocket.chat and now all enjoy the colorful richness of emojis, and in particular animated emoticons such as the :partyparrot: that so much helps productivity.
But there's a latent feeling something still is missing and the answer is simple: audio emojis! We need a feature to send audio emojis to the group and individuals that play on the recipients phones/speakers no matter what. They can be short, they can be looped, same as image emojis they need to catch attention and not allow the user to focus on something else than the chat, e.g. a smart burping to be sent every day after dinner, a looped very funny laughing when somebody announces to have broken the CI system shortly before the release or just some gulping noise which is what you preferably want to do with the :partyparrot:
over 1 year
5 hacker ♥️.
Has no hacker:
There is a lack of testing for our infrastructure code, in the chef part. While we have openstack tests that indicate that the chef cookbooks did their work (kind of) there is multitude of small details that can get away and not come up in the openstack tests that refer to infrastructure and changing cookbooks can lead to disasters without proper testing.
Introducing kitchen into the equation with a mix of docker to test how if cookbooks work and deploy exactly as we expect them to. It will make it easier to make changes to some more complex cookbook and test them in a real deployment, without having to wait for mkcloud to do a full run. It also means that its easier and faster to test them locally as we dont need to wait for a full run of 3-5 nodes to start,install,configure but we have a ready docker image that is used as deployment node.
over 4 years
2 hacker ♥️.
Has no hacker:
The openstack-helm project run Openstack in a Kubernetes cluster using helm charts.
The goal of the project is to able to run it in OpenSUSE, and if successful as a bonus add a job that runs with OpenSUSE to the gates runs with OpenSUSE to the gates
While I run I always like exploring the world, looking for new path to walk. But of course our resources to do that are limited. So I thought that would be nice to recreate legendary places like Tolkien's maps in 3D and be free to walk around
Test automation can be fun and openQA is good at it but it has limitations. This project is meant to find out where the limits are for applications with lots of things moving on the screen, e.g. a game. Completely unrelated, web based tools become the norm for many users, e.g. when working from a chromebook or similar environments. The idea here is to try to use only web based tools and not force users to use a terminal which can be frightening :) As a third requirement: Some people are not feeling comfortable using openQA "because tests are written in Perl". This is not necessarily true because tests are rather written using a simplistic test API and only a small subset of Perl knowledge is necessary, however, we still want to support other entry points so there is Python support added in https://github.com/os-autoinst/os-autoinst/pull/1558 . To find out what this new way is capable of this project should use only that Python support and find out any restrictions.
I have casually investigated that recent open source image generation AI systems are relatively invasive of the host system if one starts to install them that way. Usually container is better but needs special configuration to access the needed hardware. I'd like to run something in a container utilizing the RDNA2 Radeon gfx card I have on my desktop computer.
Create views of OpenQATest results in Grafana, grouped i.e. for Version, Builds, Flavor, Arch, in order to have a global view list, but also capability to explore details of each test, for a more integrated faults investigation environment.