Project

General

Profile

action #108530

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

coordination #108527: [epic] os-autoinst plugins (or wheels or leaves or scrolls) for scalable code reuse of helper functions and segmented test distributions

os-autoinst plugins: x11_start_program from os-autoinst-distri-openQA dynamically loaded from another git repo size:M

Added by okurz 3 months ago. Updated 2 months ago.

Status:
Blocked
Priority:
Normal
Assignee:
cdywan
Category:
Feature requests
Target version:
Ready
Start date:
2022-03-17
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Acceptance criteria

Suggestions

  • Create a local folder having perl modules, e.g. x11_start_program from https://github.com/os-autoinst/os-autoinst-distri-openQA/blob/master/lib/susedistribution.pm#L8 without the actual needle and leave it to the test distribution to provide it.
  • Start with a local git repository, e.g. file://…
  • Afterwards provide in github repo
  • Provide the example as part of os-autoinst-distri-openQA, e.g. if a YAML file plugins.yaml exists next to a main.pm load all plugins from there
  • Provide the os-autoinst code to git clone and load the above plugins.yaml (similar to how OpenQA/Isotovideo/Utils.pm loads main.pm)
  • Use from test code like we already use stuff from "lib", e.g. with prefix "OpenQA:Plugin:…"

Out of scope

  • Needles
  • Additional helper tool

Related issues

Related to openQA Project - action #81899: [easy][beginner] Move code from isotovideo to a module size:MWorkable2021-01-08

History

#1 Updated by cdywan 3 months ago

  • Status changed from Workable to In Progress
  • Assignee set to cdywan

Let's see what I can do here

#2 Updated by cdywan 3 months ago

Here's what I have so far:

I adjusted the code to not refer to x11 since there's no x11 involved and also to use %args the way we usually do in test functions.

Note that both "plugins" and "wheels" are being used. Feel free to let it sink in and make a case for one or the other.

#3 Updated by okurz 3 months ago

I think it looks awesome. My suggestions on the global scale:

  1. Follow https://metacpan.org/pod/Perl::Critic::Policy::NamingConventions::Capitalization, so OpenQA::Wheel::Launcher, not OpenQA::Wheel::launcher
  2. It's crucial that we provide self-tests for wheels. So how aobut a simple Test::Most test case in https://github.com/kalikiana/os-autoinst-wheel-launcher which mocks everything outside the repo

#4 Updated by openqa_review 3 months ago

  • Due date set to 2022-04-12

Setting due date based on mean cycle time of SUSE QE Tools

#5 Updated by kraih 3 months ago

okurz wrote:

  1. Follow https://metacpan.org/pod/Perl::Critic::Policy::NamingConventions::Capitalization, so OpenQA::Wheel::Launcher, not OpenQA::Wheel::launcher
  2. It's crucial that we provide self-tests for wheels. So how aobut a simple Test::Most test case in https://github.com/kalikiana/os-autoinst-wheel-launcher which mocks everything outside the repo

+1 for both. And then run the tests in a GitHub Action.

#6 Updated by kraih 3 months ago

The our @EXPORT = qw(start_gui_program); in the wheel repo is a bad idea though, it should be our @EXPORT_OK = qw(start_gui_program);. Because if all wheels are using default exports it will be very very hard to keep track of which function comes from which wheel.

#7 Updated by cdywan 3 months ago

Points discussed in the unblock:

  • Add v: v0.1 to the wheels.yaml (we want this to be a string to avoid running into funny behavior once we get to e.g. v0.10)
  • Stick to the term wheels because both modules and plugins already have other meanings in openQA
  • May want needles and metadata in wheels in the future but those don't need to be specified now

#8 Updated by cdywan 3 months ago

#9 Updated by cdywan 3 months ago

  • Due date changed from 2022-04-12 to 2022-04-15

Also, I approached myself with the scrum master hat on wondering if the ticket should be resolved now. Apparently I didn't realize the overlap with my trainings going on this week. So I suggest I aim to wrap this up this week, and find out by tomorrow if I need any help.

#10 Updated by okurz 2 months ago

  • Due date changed from 2022-04-15 to 2022-04-26

If there would be more people available right now I would ask for someone else to help you. Let's look into this after the Easter Break. If done after that, good, if not we can reconsider priorities and doing a mob session.

#11 Updated by cdywan 2 months ago

okurz wrote:

If there would be more people available right now I would ask for someone else to help you. Let's look into this after the Easter Break. If done after that, good, if not we can reconsider priorities and doing a mob session.

Turns out the mocking is proving to be challenging. After several attemps I moved the relevant unit tests into another PR. Maybe it's worth looking at #81899 in this context?

#12 Updated by okurz 2 months ago

  • Due date deleted (2022-04-26)
  • Status changed from In Progress to Blocked

Hi, I agree. So let's pick up #81899 first (effectively I already started with that).

#13 Updated by okurz about 2 months ago

  • Related to action #81899: [easy][beginner] Move code from isotovideo to a module size:M added

Also available in: Atom PDF