Project

General

Profile

Actions

action #92893

closed

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

Added by ilausuch over 3 years ago. Updated about 3 years ago.

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

0%

Estimated time:

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 3 (1 open2 closed)

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

Actions
Related to openQA Project - coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetesBlockedokurz2018-09-26

Actions
Blocks openQA Project - action #76978: How to run an openQA test in 5 minutes size:MResolvedjbaier_cz2020-11-04

Actions
Actions #1

Updated by ilausuch over 3 years ago

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

Updated by ilausuch over 3 years ago

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

Updated by ilausuch over 3 years ago

  • Description updated (diff)
Actions #4

Updated by VANASTASIADIS over 3 years ago

  • Target version set to future
Actions #5

Updated by okurz over 3 years 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 Regressions/Crashes to Feature requests
  • Target version changed from future to Ready

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

Actions #6

Updated by ilausuch over 3 years 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)
Actions #7

Updated by okurz over 3 years ago

  • Priority changed from Normal to Low
Actions #8

Updated by ilausuch over 3 years 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

Actions #9

Updated by ilausuch over 3 years 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
Actions #10

Updated by mkittler about 3 years ago

  • Assignee set to mkittler
Actions #11

Updated by mkittler about 3 years 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

Actions #12

Updated by mkittler about 3 years ago

  • Status changed from In Progress to Feedback

Only waiting for the review.

Actions #13

Updated by mkittler about 3 years ago

  • Status changed from Feedback to Resolved

The PR has been merged.

Actions #14

Updated by mkittler about 3 years ago

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

Also available in: Atom PDF