action #115418
closed
Setup ow19+20 to be able to run MM tests size:M
Added by mkittler over 2 years ago.
Updated about 2 years ago.
Description
Acceptance criteria¶
- AC1: ow19+20 are capable (and configured by adding the "tap" worker class) to run MM tests
- AC2: GRE tunnels are configured to allow traffic between ow19+20 and existing MM workers ow1+4+7
Suggestions¶
- Come up with a scripted solution as touching configuration files manually on now 5 workers (ow19+20 and existing ow1+4+7) would be come quite tedious.
- Our salt states already show how especially the creation of the GRE tunnel config (
/etc/wicked/scripts/gre_tunnel_preup.sh) can be automated using a jinja template. However, we'd preferably stay independent of using the salt machinery here.
- Writing a simple script that logs into all relevant worker hosts and runs the appropriate commands should be quite simple. Note that when using Perl we could also utilize the Mojolicious template system for generating files. (It can easily be used outside of the context of a web application, see this example.)
- As a general reference, look into documentation on https://open.qa/docs/#_tap_based_network and our salt states and what has already been configured on ow1+4+7.
- Related to action #111473: Get replacements for imagetester and openqaworker1 size:M added
- Subject changed from Setup ow19+20 to be able to run MM tests to Setup ow19+20 to be able to run MM tests size:M
- Status changed from New to Workable
- Related to action #115547: openqaworker20 fails to boot, broken hardware size:M added
Note that ow20 is currently broken, see #115547. So I'd exclude it for now from this ticket.
Note: This ticket is not blocked. ow19 can be configured for this.
- Assignee deleted (
dheidler)
- Status changed from Workable to Feedback
- Assignee set to livdywan
We got as far as verifying that the generated configuration looks sensible. Whether this setup works properly still needs to be confirmed with actual jobs; and no change to work classes was made for now.
cdywan wrote:
We got as far as verifying that the generated configuration looks sensible. Whether this setup works properly still needs to be confirmed with actual jobs; and no change to work classes was made for now.
Did you also configure the GRE tunnel so that all workers can reach each other?
favogt wrote:
cdywan wrote:
We got as far as verifying that the generated configuration looks sensible. Whether this setup works properly still needs to be confirmed with actual jobs; and no change to work classes was made for now.
Did you also configure the GRE tunnel so that all workers can reach each other?
It's all in the script. If the script does it the answer is yes 😉️
Seems like @okurz was also working on a script to do the same thing: #119008#note-17
I'll pick it up again. I had left this on the side due to other infra tickets but it seems fine to continue now.
- Assignee changed from livdywan to favogt
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
I'll do some more tests tomorrow and if they look good I'll add the tap class to both.
I did it the other way around: Add the tap class and see what happens. So far no issues observed.
- Related to action #121789: MultiMachine tests lose ability to communicate added
- Related to action #133025: Configure Virtual Interfaces instructions do not work on Leap 15.5 size:M added
Also available in: Atom
PDF