Project

General

Profile

action #92893

containers, docker-compose: Ensure that the scheduler can connect to the websockets container size:M

Added by ilausuch 5 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Feature requests
Target version:
Start date:
2021-05-20
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Motivation

Trying to complete the task #76978 I found a problem in the webui container. It cannot connect to the scheduler and the jobs still unscheduled

scheduler_1      | -- Blocking request (http://127.0.0.1:9527/api/send_job)
scheduler_1      | -- Connect 41d600104970be636ece6296a21d1bdc (http://127.0.0.1:9527)

It could be easily fixed adding OPENQA_WEB_SOCKETS_HOST: "websockets" to the scheduler declaration

But then an other problems happens:

scheduler_1      | -- Client <<< Server (http://websockets:9527/api/send_job)
scheduler_1      | HTTP/1.1 403 Forbidden\x0d
scheduler_1      | Content-Length: 26\x0d
scheduler_1      | Server: Mojolicious (Perl)\x0d
scheduler_1      | Date: Thu, 20 May 2021 10:24:45 GMT\x0d
scheduler_1      | Content-Type: application/json;charset=UTF-8\x0d
scheduler_1      | \x0d
scheduler_1      | {"error":"Not authorized"}

This happens when we launch a web UI openQA using the docker-compose, and try to run a job (using clone_job)

Acceptance Criteria

  • AC 1: scheduler can connect to websockets without problems

Suggestions

  • Investigate the auth method to these services. Maybe the auth method is only localhost
  • Check that the client.ini has the correct credentials

References

See the comments at #92833#note-6


Related issues

Related to openQA Project - action #92833: containers: Web UI cannot connect to schedulerResolved2021-05-192021-06-04

Related to openQA Project - coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetesBlocked2018-09-262021-11-05

Blocks openQA Project - action #76978: How to run an openQA test in 5 minutesNew2020-11-04

History

#1 Updated by ilausuch 5 months ago

  • Related to action #92833: containers: Web UI cannot connect to scheduler added

#2 Updated by ilausuch 5 months ago

  • Blocks action #76978: How to run an openQA test in 5 minutes added

#3 Updated by ilausuch 5 months ago

  • Description updated (diff)

#4 Updated by VANASTASIADIS 5 months ago

  • Target version set to future

#5 Updated by okurz 4 months ago

  • Subject changed from containers: the scheduler cannot connect to the websockets container to containers, docker-compose: the scheduler cannot connect to the websockets container
  • Category changed from Concrete Bugs to Feature requests
  • Target version changed from future to Ready

Changing to "Feature requests" as this never worked so not a regression.

#6 Updated by ilausuch 3 months ago

  • Subject changed from containers, docker-compose: the scheduler cannot connect to the websockets container to containers, docker-compose: Ensure that the scheduler can connect to the websockets container
  • Description updated (diff)

#7 Updated by okurz 3 months ago

  • Priority changed from Normal to Low

#8 Updated by ilausuch 3 months ago

Last week appeared this ticket in our meetings and I had an idea to check that I don't wanted to forget

In the scheduler container we don't have the client.ini with the credentials. This could be a clue to follow

4adc570f1117:/data/conf # ls
database.ini openqa.ini

#9 Updated by ilausuch 3 months ago

  • Subject changed from containers, docker-compose: Ensure that the scheduler can connect to the websockets container to containers, docker-compose: Ensure that the scheduler can connect to the websockets container size:M
  • Status changed from New to Workable

#10 Updated by mkittler about 2 months ago

  • Assignee set to mkittler

#11 Updated by mkittler about 2 months ago

  • Status changed from Workable to In Progress

Before I could actually get to the point that a containerized worker successfully connects to my containerized web UI I had to fix many issues. The NGINX configuration was not even effective because it was stored in the wrong place. The source of this particular problem was that the environment variables OPENQA_*_HOST were not configured correctly. There was also no hint in the documentation how to configure credentials within client.conf so I assume the lack of this configuration was also a problem.

PR to fix many of the issues I've came across, including the one mentioned in the ticket description and better documentation: https://github.com/os-autoinst/openQA/pull/4160

#12 Updated by mkittler about 2 months ago

  • Status changed from In Progress to Feedback

Only waiting for the review.

#13 Updated by mkittler about 1 month ago

  • Status changed from Feedback to Resolved

The PR has been merged.

#14 Updated by mkittler 8 days ago

  • Related to coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes added

Also available in: Atom PDF