Phase 1: Melkor

Comments

• 

  over 8 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).

×
Edit Comment 2406
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
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](https://docs.saltstack.com/en/latest/topics/reactor/). Furthermore, we investigated the two `openqa-minimal` and `openqa-minimal-full` workflows and we spotted 2 missing things (*no prepare*, *no diff logs*).
 
×
Reply to pgeorgiadis
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).
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  over 8 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.

×
Edit Comment 2434
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
## 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](https://github.com/SUSE/connect/wiki/SCC-API-(Implemented)#packagelist-search) or [WebUI](https://scc.suse.com/packages) 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](https://en.wikipedia.org/wiki/KISS_principle) 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.
 
×
Reply to pgeorgiadis
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.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
 
• 

  over 8 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.

×
Edit Comment 2472
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview
## 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](https://hackweek.suse.com/15/projects/suse-music-ian-space).
 
×
Reply to pgeorgiadis
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.
---
# A First Level Header
## A Second Level Header

Use one asterisk to *emphasize*

Use two asterisks for **strong emphasis**

- Use hyphens
- for unordereed
- lists

This is an [link to example.com](http://example.com/)

This is an image ![an openSUSE geeko icon](https://en.opensuse.org/images/d/d0/Icon-distribution.png)

This is a user link @hans

This is a project link hw#some-cool-title
More Complex Markdown Help
Formatting Help
• Edit
• Preview