Phase 1: Melkor

After gathering the feedback of qam (transcription of brainstorming for problems and requirements), it's time to start fixing things. Let's build the first step of a shipping skeleton solution that addresses all of the problems listed in the aforementioned document. (draft)

Let's start hacking \m/

Melkor

And he descended upon Arda in power and majesty greater than any other of the Valar, as a mountain that invades in the sea and has its head above the clouds and is clad in ice and browned with smoke and fire; and the light of the eye of Melkor was like a flame that withers with heat and pierces with a deadly cold - The Silmarillion

All the components used in the project will be named after the J.R.R. Tolkien's trilogy Lord of the Rings.

Looking for mad skills in:

Nothing? Add some keywords!

This project is part of:

Hack Week 15


Comments

  • pgeorgiadis
    over 2 years ago by pgeorgiadis | Reply

    Day 1:

    We gathered both the minimal (hard-req) and the actual (more practical) the addons we use in qam-nue for our x86_64, ppcle64 and s390x refhosts using the information from refhosts.xml and the refdb (thx Heiko for the tip). We also got more business-related information some on modules from our SLE Project Managers. Furthermore, we contacted Infrastructure about providing us with best practices about how to trigger our Salt Master (acts like a KVM controller) when openQA Maintenance Incident is done. The straightforward solution here is using Salt Reactor System. Furthermore, we investigated the two openqa-minimal and openqa-minimal-full workflows and we spotted 2 missing things (no prepare, no diff logs).

  • pgeorgiadis
    about 2 years ago by pgeorgiadis | Reply

    Day 2

    We collected more feedback about the revenue of our extensions and modules from the Product Managers. Also, we talked with Artem from SCC team and we found out that there's a beta tool package list search or WebUI that provides us with this knowledge:


    Given we know the exact name of a package, when we request info about it, then it returns the modules/extensions from which we can install it.


    Also, abonini noticed (and we verified it with the release managers) that some packages might be available in more than one repositories. This means, that it might be that there are dependency conflicts over there, that we are not currently investigating. As a result, we are rethinking the use-case of taking the qcow2 image from openQA, because of the following limitations:

    1. ATM it's only SLES without any modules or extensions (which is a supported scenario, so we still want this).
    2. It's too difficult to create dynamically testsuites on-the-fly per update. We addressed that to szarate and we are waiting for feedback.
    3. openQA is using amqp and rabbitmq in order to inform others about its events (e.g. talk to IRC). We could use this, but the better approach according to our plan would be to use natively Saltstack technology.
    4. It's not easy to tag a specific worker for maintenance incidents. If we can do that, then we could install salt and use this worker as minion that will notify our other minion (in this case, a KVM Hypervisor) in order to copy the image and spawn the required guests.
    5. The installation of the qam update is not great.

    On the bright side, okurz helped us by writing a ampq.py script that is listening on the openqa.suse.de for maintenance incidents if the result is passed, then it returns you the link of the qcow2 image. Unfortunately, it seems that we don't publish the image (have to talk to coolo about it). In any case, I will upload the script in github later this week. Many thanks to Oliver (!) for the help and the extensive explanation of the inner workings of openQA events.

    The alternative is to keep openQA only for the minimal scenarios, and somehow find a way to have qcow2 images for the rest of the testing coverage. This can be achieved by many ways, but first we have to try to use openQA and make it happen there -- because it feels the right place for this job.

  • pgeorgiadis
    about 2 years ago by pgeorgiadis | Reply

    Day 3:

    Extensive discussion with okurz talking about a lot of interesting topics around the continuous integration and continuous delivery and in general about the concepts of lean and agile methodologies. The rest of the day was dedicated to another Hackweek project.

Similar Projects

This project is one of its kind!