action #153499
closedcoordination #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
0%
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¶
- Try out a container deployment yourself because it's so easy
- Check if the developer mode works or how to get it work. For this read http://open.qa/docs/#debugdevelmode
- Ensure our tests cover that. Likely openQA-in-openQA tests are helpful here
- Implement what is missing. Consider configurable ports and port deltas, see https://github.com/os-autoinst/openQA/pull/5435
- Where needed extend documentation
- As necessary research about https://docs.podman.io/en/latest/markdown/podman-port.1.html or similar to find out what ports containers expose
Updated by mkittler 4 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:
- 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.
Updated by mkittler 3 months ago
Just for the record, a PR was created: https://github.com/os-autoinst/openQA/pull/5435
Updated by mkittler 3 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:
- I did the mistake of cloning an openQA-in-openQA test so I ran into the problem that
perl-Inline-Pythonwas 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.gitandNEEDLES_DIR=https://github.com/os-autoinst/os-autoinst-needles-openQA.gitmanually 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.
Updated by mkittler 3 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.
Updated by okurz 3 months ago
https://github.com/os-autoinst/openQA/pull/5477 for further enhancement on that
Updated by livdywan 3 months ago
- Copied to action #155473: Avoid the need for API keys within the same container/client added
Updated by mkittler 3 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.
Updated by okurz 3 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"
Updated by mkittler 3 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.