Feature to enable custom repo during prepare step

[juk]

That would be helpful to have a keyword to enable custom repositories during "prepare" step Something like below:

prepare:
    repos:
        - https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/
        - https://dl.fedoraproject.org/pub/epel/9/Everything/source/tree/

note, there is functionality to enable copr repositories in place.

[idorax]

@juk, if a repo url (e.g. https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/) is specified via attribute repos, what you'd like to have is to create a .repo file in directory /etc/yum.repos.d in guest?

[lukaszachy]

What about ways to specify gpgcheck and other options as skip_if_unavailable? FTR Beaker can't do that - it just accepts URL.

[idorax]

@lukaszachy, would you please explain more about skip_if_unavailable?

How about the FMF block looks like in the following? @juk and @lukaszachy

prepare:
    repos:
    -   url: https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/
        gpgcheck: 1
        gpgkey: file:///etc/pki/rpm-gpg/FOO1001
        # ...other options...
    -   url: https://dl.fedoraproject.org/pub/epel/9/Everything/source/tree/
        gpgcheck: 0
        gpgkey: file:///etc/pki/rpm-gpg/FOO1002
        # ...other options...

[lukaszachy]

Does user prefer to continue if repo is not available (skip_if_unavailable=True) or make dnf command fail ? For example copr repositories added by dnf copr enable have it set to True

[juk]

@idorax Right, create a .repo file Not sure if extra options like gpgcheck/gpgcheck are necessary We could have gpgcheck=0. Assuming user running tests know what they doing But I'll leave it up to you to decide

@lukaszachy yes, enabled=1, skip_if_unavailable=1

[idorax]

Paste a sample .repo file right here before implementation. e.g.

$ sudo cat /etc/yum.repos.d/beaker-Fedora.repo 
[beaker-Fedora]
name=beaker-Fedora
baseurl=http://FOO/released/fedora/branched/Fedora-36-20220506.n.0/Everything/x86_64/os/
enabled=1
gpgcheck=0
skip_if_unavailable=1

[lukaszachy]

FTR - Ansible is able to create repo already https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_repository_module.html

It really depends on the use case to say what gpgcheck and skip_if_unavailable should be set to.

skip_if_unavailable=1 is necessary for not reliable repos if dnf queries are supposed to run often on the SUT. However one might end up with invalid package version if this happens in install (e.g. added repo contains updated rpm but repo was not available and dnf installed rpms from base repository). So whole run is invalid and to make it worse this is something to check explicitly for. So I'd say safe default is skip_if_unavailable=0 and let user to set to to 1 (user should know what they are doing).

gpgcheck depends on added repo - If it is unsigned compose then you have no other option but to ignore signatures. However for most repos (including epel from the example) I'd say one should check signatures.

I'd vote for skip_if_unavailable=0 and gpgcheck=1 with options to set them explicitly.

[juk]

@lukaszachy, I understand your concerns. But at the end of the day it's a test environment that would be torn down after test. Not sure how often skip_if_unavailable=0 and gpgcheck=1 would safe a user from issues? This might cause more problems with custom repos and users might end up specifying skip_if_unavailable=1 and gpgcheck=0 every time

I would still suggest make it the most permissive by default and have an option for concerned users to set skip_if_unavailable=0 and gpgcheck=1.

But I'll leave it up to you

[lukaszachy]

Not sure how often skip_if_unavailable=0 and gpgcheck=1 would safe a user from issues?

Lets say that you test update of package foo: You add repo containing update as skip_if_unavailable=1 but network issue happens during prepare.install phase and old version of foo is installed from base repository. Prepare install successfully passes. Unless there is fail or error in some test your run is success and you happily think that your update is working. However you haven't tested it at all.

gpgcheck=1 usually point to infra issues connected with compose creation (e.g. scratch build slipped into official compose) or that wrong key is used to sign rpms in the repo.

[juk]

Right, in a kernel world we always make sure we have the right package (nvr) installed before we test.

Anyways, we could always change defaults later

[lkotek]

Hi @idorax, I was experimenting a bit with this feature before I noticed issue is already taken :smile: I tried to address it with slightly different approach, you can see it in my private branch: https://github.com/teemtee/tmt/commit/c96ca22872291dec7b210d44efd0d0640ce48697 - I just wanted to share it in case you find it interesting.

[idorax]

Hi @lkotek, thank you very much for letting me know your solution. Currently provision supports:

  artemis .............. Provision guest using Artemis backend
  connect .............. Connect to a provisioned guest using ssh
  local ................ Use local host for test execution
  container ............ Create a new container using podman
  virtual.testcloud .... Local virtual machine using testcloud

Looks your branch supports local, does your branch support connect? If yes, would you please share the tmt command? I'd like to have a try, thanks!

[lkotek]

Hi @lkotek, thank you very much for letting me know your solution. Currently provision supports:

  artemis .............. Provision guest using Artemis backend
  connect .............. Connect to a provisioned guest using ssh
  local ................ Use local host for test execution
  container ............ Create a new container using podman
  virtual.testcloud .... Local virtual machine using testcloud

Looks your branch supports local, does your branch support connect? If yes, would you please share the tmt command? I'd like to have a try, thanks!

@lkotek Sorry for the late answer I was on vacation meanwhile. I tried it only with virtual (and it worked correctly), but as far I can say it should be provision agnostic.

[thrix]

@lkotek hi any update on this one? Seems it is a KQE blocker: https://issues.redhat.com/browse/KQE-5

[idorax]

@thrix I once had a patch which is based on the code of @lkotek. Let me update the patch:

• Define keys in dataclass,
• Support to add multiple repositories.

How about 1.28 or 1.29?

[lkotek]

Hi @thrix, @idorax was quicker in answering. Let me just confirm what he stated in previous comment :wink:

[idorax]

Hi @lukaszachy , @happz and @lkotek , since multiple repos should be supported, the fmf block would be looked like:

prepare: repo
repo:
- name: repo01
  baseurl: http://beaker.engineering.redhat.com/harness/Fedora39/
  gpgcheck: false
  gpgkey: null
  skip-if-unavailable: true
  enabled: true
- name: repo02
  baseurl: http://beaker.engineering.redhat.com/repos/14594884
  gpgcheck: true
  gpgkey: https://foo.com/a/b/c/key
  skip-if-unavailable: false
  enabled: false

right?

And there are many parameters to define a repo, what parameters are required so as to meet the needs of this issue? Please help to clarify, thanks!

[happz]

Feels like re-inventing yum-repository module of Ansible, https://docs.ansible.com/ansible/latest/collections/ansible/builtin/yum_repository_module.html#examples :) If nothing else, the page could provide nice guidance on WRT required fields and default values for the rest.

But to make it clear, wouldn't a simple Ansible playbook & ansible phase in prepare? be an acceptable solution? :)

[idorax]

But to make it clear, wouldn't a simple Ansible playbook & ansible phase in prepare? be an acceptable solution? :)

@happz, the solution you suggested looks better and easier as we have plugin ansible. @lukaszachy, @lkotek, what do you think?

[lkotek]

@idorax What I liked at my original solution was it is lightweight and covers the most of the scenarios, but since there is ansible I think using my solution would be more like reinventing the wheel.

So, I agree, let's stick to ansible-based solution :+1:

[juk]

For an add-hoc testing when someone wants to kick a test job with a new scratch build would they be able to provide an "ansible" repo with a command line tools tmt or testing-farm?

[juk]

repos array with only repo names and urls and default settings behind (like beaker 'repos' tag) would be great

[idorax]

repos array with only repo names and urls and default settings behind (like beaker 'repos' tag) would be great

Hi @juk, do you mean you'd like to let TMT support to create ansible repo then you can use ansible to create your custom repos?

[juk]

@idorax, to quickly kick tests. Something like below tmt run -v -d -a plan --name /distribution/kernelinstall --environment "KERNELARGNAME=kernel KERNELARGVERSION=5.14.0-363.3029_996505260.el9" --repo https://<storage>/internal/<build_id>/\$basearch/5.14.0-363.3029_996505260.el9.\$basearch provision -h minute -i rhel-9.3

[happz]

A couple of points discussed on Tuesday in tmt hacking session: a new plugin might easily turn into a duplication of what yum_repository Ansible module is doing already, which is not something tmt developers would like to see happening. Therefore sentiment was using ansible and a playbook would be the recommended way to resolve the need for ad hoc repositories.

That said, there is also a possibility to extend ansible plugin to accept ad hoc commands in a way similar to ansible command, https://docs.ansible.com/ansible/latest/command_guide/intro_adhoc.html. The usage might then look like this:

prepare:
  - how: ansible
    module: yum_repository
    module-args:
      baseurl: http://foo.dot.com/some/repo
      description: A repository
      gpgcheck: 1

tmt run ... prepare --insert \
                    --how ansible \
                    --module yum_repository \
                    --module-args "baseurl=http://foo.dot.com/some/repo description=\"A repository\" gpgcheck=1"

This would not put the burden of maintaining a dedicated plugin on tmt developer while allowing users to take advantage of existing, ready-to-use functionality solving the original request. Filed https://github.com/teemtee/tmt/issues/2433 to track this feature.

@juk WDYT?

[psss]

Nice idea! Sounds like a very elegant solution to me.