Project

General

Profile

Actions

action #153499

closed

coordination #127031: [saga][epic] openQA for SUSE customers

coordination #80150: [epic] Scale out openQA: Easier openQA setup

Ensure the openQA developer mode works straight-forward in the container setup when following our documentation size:M

Added by okurz 3 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2024-01-13
Due date:
% Done:

0%

Estimated time:

Description

Motivation

Based on reports by users, e.g. in https://matrix.to/#/!dRljORKAiNJcGEDbYA:opensuse.org/$LbL5oeNDTwzikKhlZdH39GOSkR2qZ7Nvoie6Yvx1Khs developer mode might not work straight out of the box in the container setup:

dbrouwer @Sam Thursfield i'm curious if you got developer mode working in a container? Yesterday adamw pointed out that we had the same problem experimenting with running openqa remotely in containers. I eventually had to comment out the logic in makeWsUrlAbsolute() that expects the port to be 80 or 443 since I wanted to run a rootless container and was pushing port 80 to 8081. Curious if you did the same or if you found another way around it?

Acceptance criteria

  • AC1: The openQA developer mode in openQA live run is ensured to work based on automatic installation or documentation in the common container setup of openQA

Suggestions


Related issues 1 (0 open1 closed)

Copied to openQA Project - action #155473: Avoid the need for API keys within the same container/clientRejected2024-01-13

Actions
Actions #1

Updated by mkittler 3 months ago

I eventually had to comment out the logic in makeWsUrlAbsolute() that expects the port to be 80 or 443 since I wanted to run a rootless container and was pushing port 80 to 8081.

I suppose we need to make the behavior of that function configurable (e.g. via openqa.ini). We need to support:

  1. customized ports while still using Apache/NGINX as reverse proxy. That's what this ticket is asking for.
  2. using a direct connection without reverse proxy where each service is using its own (non-standard) port. That's what a typical development setup requires to work and the makeWsUrlAbsolute() function currently behaves to support that use case.
Actions #2

Updated by mkittler 3 months ago

Just for the record, a PR was created: https://github.com/os-autoinst/openQA/pull/5435

Actions #3

Updated by okurz 3 months ago

  • Target version changed from Tools - Next to Ready

Yes, that's why we should pick this up into our backlog now

Actions #4

Updated by okurz 3 months ago

  • Subject changed from Ensure developer mode works in the container setup to Ensure the openQA developer mode works straight-forward in the container setup when following our documentation size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions #5

Updated by mkittler 2 months ago

  • Assignee set to mkittler
Actions #6

Updated by mkittler 2 months ago · Edited

  • Status changed from Workable to In Progress

I could reproduce the problem with our single-container setup as it also exposes everything under one port but not the standard port. Adding service_port_delta = 0 to the config fixes that (so https://github.com/os-autoinst/openQA/pull/5435 works). Note that I found the command for the single-container setup mentioned in our documentation not very helpful. For a normal user it would probably quite hard to figure out how to get an actual job running¹. Restarting the web UI to apply some config change was also very annoying without systemd or any similar mechanism (one needs to kill openqa manually and then run the openqa-daemon script as the right user again manually).

Just for the record: This config is not required by the docker-compose setup as it uses the standard ports 80 and 443 and in addition to that also exposes the regular ports for accessing the services directly (see EXPOSE 80 443 9526 9527 9528 9529 in the Dockerfile).


¹ There are just many obstacles:

  1. I did the mistake of cloning an openQA-in-openQA test so I ran into the problem that perl-Inline-Python was not installed.
  2. KVM is not enabled so I had to clone with QEMUCPU=Haswell-v4.
  3. For a normal user it might not be obvious how to invoke openqa-clone-job to reach the instance inside the container and download the assets inside the container.
  4. Where do tests and needles come from? I had to specify CASEDIR=https://github.com/os-autoinst/os-autoinst-distri-openQA.git and NEEDLES_DIR=https://github.com/os-autoinst/os-autoinst-needles-openQA.git manually when cloning because the command doesn't include mount relevant directories into the container. Using Git repos like that is probably not what people want to start developing tests.
Actions #7

Updated by mkittler 2 months ago · Edited

This PR will fix AC1: https://github.com/os-autoinst/openQA/pull/5471

PR for improving the out-of-box experience (see previous comment): https://github.com/os-autoinst/openQA/pull/5472

Note sure about perl-Inline-Python. Probably we had reasons for leaving it out and I guess this is only a problem for openQA-in-openQA tests at this point.

Actions #8

Updated by mkittler 2 months ago

  • Status changed from In Progress to Feedback
Actions #9

Updated by okurz 2 months ago

  • Due date set to 2024-02-27
Actions #10

Updated by okurz 2 months ago

https://github.com/os-autoinst/openQA/pull/5477 for further enhancement on that

Actions #11

Updated by livdywan 2 months ago

  • Copied to action #155473: Avoid the need for API keys within the same container/client added
Actions #12

Updated by mkittler 2 months ago

With https://github.com/os-autoinst/openQA/pull/5471 merged I'd consider the AC fulfilled and we can do further general improvements about the containerized setup and its documentation in other tickets.

Actions #13

Updated by okurz 2 months ago

  • Status changed from Feedback to Workable

Hm, not quite there. Our AC says "The openQA developer mode in openQA live run is ensured to work" stressing the word "ensured". Right now it's only a variable being set but what prevents us from breaking that e.g. when the variable is renamed?

From the "Suggestions": "Ensure our tests cover that. Likely openQA-in-openQA tests are helpful here"

Actions #14

Updated by mkittler 2 months ago

  • Status changed from Workable to Feedback

That really goes to far. It was hard enough to get a test (that is extensive enough to open the developer mode) running at all inside the container manually. So far our tests only start the container, check whether the web UI responds via curl and that's it. Running a test in a way that allows us to inspect the behavior of the developer mode is not trivial (as we see in the fullstack/integration tests) and doing it in this containerized setup makes it even harder.

Note that when renaming the variable one hopefully does a full search & replace. But it is actually unlikely that we will accept a PR to rename the variable (or setting) because it would be a breaking change for users for no good reason.

Actions #15

Updated by okurz 2 months ago

  • Due date deleted (2024-02-27)
  • Status changed from Feedback to Resolved

ok, fine

Actions

Also available in: Atom PDF