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 4 months ago.
Updated 3 months ago.
Category:
Feature requests
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¶
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:
- customized ports while still using Apache/NGINX as reverse proxy. That's what this ticket is asking for.
- 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.
- Target version changed from Tools - Next to Ready
Yes, that's why we should pick this up into our backlog now
- 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
- 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:
- I did the mistake of cloning an openQA-in-openQA test so I ran into the problem that
perl-Inline-Python was not installed.
- KVM is not enabled so I had to clone with
QEMUCPU=Haswell-v4.
- 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.
- 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.
- Status changed from In Progress to Feedback
- Due date set to 2024-02-27
- Copied to action #155473: Avoid the need for API keys within the same container/client added
- 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"
- 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.
- Due date deleted (
2024-02-27)
- Status changed from Feedback to Resolved
Also available in: Atom
PDF