QA (public)

Two questions I have: does a build also consider aggregates?

consider i.e Wicked: https://openqa.suse.de/tests/overview?distri=sle&&build=%3A32459%3Awicked&&build=:32458:wicked&build=:32460:wicked

Where this search is only showing single incidents, but doesn't show aggregate updates :D

szarate wrote in #note-2:

Two questions I have: does a build also consider aggregates?

Yes.

What's the second question?

plus https://gitlab.suse.de/qa-maintenance/bot-ng/-/merge_requests/68 , merged. https://github.com/openSUSE/qem-bot/pull/177 merged.

https://gitlab.suse.de/qa-maintenance/bot-ng/-/jobs/2502425#L57

ModuleNotFoundError: No module named 'pika'

The PR was merged and I configured the pipeline under https://gitlab.suse.de/qa-maintenance/bot-ng/-/pipeline_schedules.

I created https://sd.suse.com/servicedesk/customer/portal/1/SD-154403 to allow the traffic because the pipeline currently runs into a connection error.

Maybe we also still need to take care that the TLS certificate is available within the container (like what was done for #158907). The TLS certificates are already installed in the container (see https://build.suse.de/projects/QA:Maintenance/packages/openSUSE-Leap-Container/files/Dockerfile?expand=1).

We decided to give https://itpe.io.suse.de/open-platform/docs/docs/category/getting-started a try instead.

Failed with pika.exceptions.AMQPConnectionError now, see https://gitlab.suse.de/qa-maintenance/bot-ng/-/jobs/2512747

Once we have access we'd probably need build an RPM package for bot-ng and a container image installing it (according to https://itpe.io.suse.de/open-platform/docs/docs/getting_started/quickstart/#build-rpm-packages-and-container-images). We could maybe also skip the packaging step and add clone the Git repo directly when building the container. That might simplify things and we don't need to build anything here anyway.

By the way, I tried to improve the error handling of the AMQP code so we get more than just the exception type AMQPConnectionError: https://github.com/Martchus/qem-bot/pull/new/amqp-2
This didn't work, though. It looks like the error message is actually shown also without such a change, e.g.:

…
  File "/usr/lib64/python3.11/socket.py", line 962, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -3] Temporary failure in name resolution

However, in case of a connection error (and not a DNS error) there simply seems to be no error message available because even with my change all I get is:

./bot-ng.py --configs ../metadata -t 1234 --dry amqp --url amqp://10.145.56.20
2024-04-22 17:33:31 ERROR    Establishing AMQP connection to 'amqp://10.145.56.20': 

So this change makes things even worse as we now don't even know that it is an AMQPConnectionError. Considering https://pika.readthedocs.io/en/stable/modules/exceptions.html#pika.exceptions.AMQPConnectionError the error class AMQPConnectionError is probably the best we can get in certain cases.

Of course we could also just use https://build.suse.de/projects/QA:Maintenance/packages/openSUSE-Leap-Container/files/Dockerfile again and to the checkout manually like in https://gitlab.suse.de/qa-maintenance/bot-ng/-/blob/master/.gitlab-ci.yml#L47.

Otherwise I suppose https://build.suse.de/project/show/QA:Maintenance would be the right place to add a new container (based on the existing openSUSE-Leap-Container in the same project).

mkittler wrote in #note-20:

Of course we could also just use https://build.suse.de/projects/QA:Maintenance/packages/openSUSE-Leap-Container/files/Dockerfile again and to the checkout manually like in https://gitlab.suse.de/qa-maintenance/bot-ng/-/blob/master/.gitlab-ci.yml#L47.

Otherwise I suppose https://build.suse.de/project/show/QA:Maintenance would be the right place to add a new container (based on the existing openSUSE-Leap-Container in the same project).

I suggest to not use IBS unless we have to. Shouldn't be too hard to create our own variant in OBS.

to be explicit as the ticket URL was some comments back: Blocked on https://sd.suse.com/servicedesk/customer/portal/1/SD-154403

Since I don’t know how to answer your questions myself I asked about it on Slack: https://suse.slack.com/archives/C04S88VCHS7/p1714640151238429

We got a subnet in the SD ticket but probably need help to configure it so I'm waiting for a response in the SD ticket.

okurz wrote in #note-25:

to be explicit as the ticket URL was some comments back: Blocked on https://sd.suse.com/servicedesk/customer/portal/1/SD-154403

Conversation on-going (checking it since our SLO's require an update within the next couple days)

Maybe we should nevertheless respond somehow in the SD ticket. (Even though we don't fully understand the options mentioned there.)

mkittler wrote in #note-31:

Maybe we should nevertheless respond somehow in the SD ticket. (Even though we don't fully understand the options mentioned there.)

Honestly I don't know what the difference between the last two suggestions from Martin is. I would consider saying something like, "if we deploy qembot on op, which one is the easiest way forward for everyone involved?".

I wonder why we decided to use containers on OpenPlatform rather than gitlab CI. In https://sd.suse.com/servicedesk/customer/portal/1/SD-154403 Ruediger Oertel 2024-04-19 12:50 commented

looks like this was already discussed elsewhere and the approach with the gitlap runners was not really optimal for what was being done.

and later on Marius Kittler 2024-04-19 14:29 says

The pipeline is still running into the pika.exceptions.AMQPConnectionError. Not sure whether the DNS change is already effective.
Probably we’re now going with openplatform anyway - although it’ll be still great if the GitLab pipeline worked as short-term solution.

and later Marius Kittler 2024-06-10 12:00

Our first attempt of using GitLab runners was considered an abuse so we moved the container to OpenPlatform

In line with our SLO's somebody needs to pick this up now, hence raising to High

To give this ticket more priority I moved more tickets out of the current backlog and have reduced the priority of others which leaves this ticket as the most important unassigned workable ticket in the tools team dev backlog.

However reconsidering right now mkittler and me think that gitlab CI is providing the benefits of reporting, alerting, secrets management over containers in OpenPlatform. Also by now with https://sd.suse.com/servicedesk/customer/portal/1/SD-154403 progressed gitlab CI runners should have access to rabbit.suse.de so we can continue with our original plan.

The SD ticket is seemingly blocked on https://jira.suse.com/browse/PLAT-499 which has been "in progress" since May. Do we assume this is usable right now or should we block on this?

Or do we go ahead with GitLab despite the concerns from others? If so, I guess we need to check that it works.

livdywan wrote in #note-47:

However reconsidering right now mkittler and me think that gitlab CI is providing the benefits of reporting, alerting, secrets management over containers in OpenPlatform. Also by now with https://sd.suse.com/servicedesk/customer/portal/1/SD-154403 progressed gitlab CI runners should have access to rabbit.suse.de so we can continue with our original plan.

The SD ticket is seemingly blocked on https://jira.suse.com/browse/PLAT-499 which has been "in progress" since May. Do we assume this is usable right now or should we block on this?

Or do we go ahead with GitLab despite the concerns from others? If so, I guess we need to check that it works.

we go ahead with gitlab and make it work.

Gitlab CI runners seem to not have access yet, as i cannot reproduce the pika.exceptions.AMQPConnectionError issue locally.
For me everything works fine when i create the container and reproduce the commands of the pipeline on my machine (within VPN):

$BOT_LAUNCHER ./bot-ng.py -c /etc/openqabot --token $BOT_
TOKEN $BOT_PARAMS $BOT_CMD 2>&1 | tee bot_${BOT_CMD}_log.log
+ tee bot_amqp_log.log
+ timeout --preserve-status --signal=SIGINT 230m ./bot-ng.py -c /etc/openqabot --token op
3nQAB0tT0k3n --dry --debug amqp
2024-09-27 11:04:27 INFO     AMQP listening started
2024-09-27 11:07:10 DEBUG    Received AMQP message: {'ARCH': 'x86_64',...

robert.richardson wrote in #note-52:

https://sd.suse.com/servicedesk/customer/portal/1/SD-154403

I am asking for feedback on the ticket. Also offering to discuss via chat or call as a way to agree on a solution.

I opened SD-174039 to request a dedicated cluster.