Project

General

Profile

Actions

action #155473

closed

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

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

Avoid the need for API keys within the same container/client

Added by livdywan 2 months ago. Updated 2 months ago.

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

0%

Estimated time:

Description

Motivation

The conversion spurred by #153499#note-7 brought up the question why a newly created container with openQA webUI, worker and client would require the user to know about and manually configure API keys.

Acceptance criteria

  • AC1: It is possible to run the container without manually setting up API keys already known to openQA

Suggestions

  • Containers can be stopped and re-created all the time. Consider this for the user story
  • registry.opensuse.org/devel/openqa/containers/openqa-single-instance contains all the parts from webUI to client - the API key is known by design

Related issues 2 (1 open1 closed)

Copied from openQA Project - action #153499: Ensure the openQA developer mode works straight-forward in the container setup when following our documentation size:MResolvedmkittler2024-01-13

Actions
Copied to openQA Project - action #155491: Extend documentation for single-instance-container covering at least how to trigger/clone existing jobsNew2024-01-13

Actions
Actions #1

Updated by livdywan 2 months ago

  • Copied from action #153499: Ensure the openQA developer mode works straight-forward in the container setup when following our documentation size:M added
Actions #2

Updated by livdywan 2 months ago

  • Description updated (diff)
Actions #3

Updated by okurz 2 months ago

  • Due date deleted (2024-02-27)
  • Target version changed from Ready to future
Actions #4

Updated by mkittler 2 months ago · Edited

  • Status changed from New to Rejected

This isn't actually required (so AC1 is already fulfilled). I just tested it again and it works out of the box. Sorry for the confusion about this.


In case you're interested: Yesterday - when I ran into the issue - I did the following:

$ podman exec openqa openqa-clone-job --host localhost:9526 --skip-download https://openqa.opensuse.org/tests/3935964
API key/secret for 'localhost:9526' missing. Checkout '/usr/bin/openqa-clone-job --help' for the config file syntax/lookup.

Then I configured the key completely overriding the existing config which of course made it work.

Then I tried whether I can avoid --host … and ran into the problem of missing key/secret but only because I previously overwrote the config.

Of course this is the kind of confusion one gets when having to puzzle the pieces together manually to make at least some use of the container (as the documentation suggests to run it).

Actions #5

Updated by okurz 2 months ago

  • Copied to action #155491: Extend documentation for single-instance-container covering at least how to trigger/clone existing jobs added
Actions

Also available in: Atom PDF