-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require the latest testcloud
with the race fix
#3244
base: main
Are you sure you want to change the base?
Conversation
Failed to load packit config file:
For more info, please check out the documentation or contact the Packit team. You can also use our CLI command |
2 similar comments
Failed to load packit config file:
For more info, please check out the documentation or contact the Packit team. You can also use our CLI command |
Failed to load packit config file:
For more info, please check out the documentation or contact the Packit team. You can also use our CLI command |
3a0c785
to
cf841b7
Compare
Failed to load packit config file:
For more info, please check out the documentation or contact the Packit team. You can also use our CLI command |
2 similar comments
Failed to load packit config file:
For more info, please check out the documentation or contact the Packit team. You can also use our CLI command |
Failed to load packit config file:
For more info, please check out the documentation or contact the Packit team. You can also use our CLI command |
cf841b7
to
87573ee
Compare
@thrix, according to the pipeline.log the artifacts seems to be set up correctly: "artifacts": [
{
"id": "8083948:fedora-40-x86_64",
"install": true,
"order": 30,
"packages": [
"tmt+report-junit-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt+provision-beaker-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt+test-convert-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt+all-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt+provision-virtual-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt+export-polarion-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt+provision-container-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch",
"tmt+report-polarion-1.37.dev888-1.20240927082453070315.pr3244.36.g4ee23632.fc40.noarch"
],
"type": "fedora-copr-build"
},
{
"id": "https://download.copr.fedorainfracloud.org/results/frantisekz/testcloud-wip/fedora-40-x86_64/",
"install": true,
"order": 20,
"packages": null,
"type": "repository"
}
], Any idea why the installation still fails? And picks some old build from the testcloud copr repo? |
@frantisekz, seems we finally succeeded in executing the tests! But quite many of them are red. Most of them related to reboot. But I can see one |
I am digging and experimenting through, will pick my brain here: What (I may understand wrong) seems weird... (I'll use my specific paths for the VM that actually failed and ssh attempt would reject ssh auth) if I compare public ssh keys given to the instance's cloud-init via user-data (/var/tmp/tmt/testcloud/instances/tmt-065-tshRMCFO/meta/user-data) and stored locally in /var/tmp/tmt/run-065/tests/example/plan/provision/default-2 they sometimes differ, eg.
I've double checked this should be the same instance in the multihost run:
It's possible that this sn't the culprit, that I am missing something and it's expected to behave this way... but confirmation/denial would be welcome |
Hmmm, sounds weird. @happz, do you think it could be possible that the ssh keys are somehow exchanged/misplaced between the guest instances? |
That's definitely one possible cause, but I don't see how it could happen. E.g. generated SSH key pair should be in guest's own workdir, e.g. I'd try to add more debugging lines, printing more paths and contents, trying to pinpoint on which side of the border the swap happens. We can also add guest name into the pubkey by adding But: SSH key is generated, stored in files, then
Isn't it returning a shared, mutable object to all calls once it's created? Aren't all subsequent calls to |
Yep, I added a guest name to SSH key file, plus a barrier after setting
As you can see, diff --git a/tmt/steps/provision/testcloud.py b/tmt/steps/provision/testcloud.py
index 0e12dfaa..cdcc5ff9 100644
--- a/tmt/steps/provision/testcloud.py
+++ b/tmt/steps/provision/testcloud.py
@@ -12,6 +12,7 @@ import types
from collections.abc import Iterator
from string import Template
from typing import TYPE_CHECKING, Any, Optional, Union, cast
+import threading
import click
import pint
@@ -39,6 +40,9 @@ if TYPE_CHECKING:
from tmt.hardware import Size
+BARRIER = threading.Barrier(3)
+
+
libvirt: Optional[types.ModuleType] = None
testcloud: Optional[types.ModuleType] = None
@@ -759,7 +763,7 @@ class GuestTestcloud(tmt.GuestSsh):
self.debug('Generating an ssh key.')
key_name = f"id_{key_type if key_type is not None else 'rsa'}"
self.key = [self.workdir / key_name]
- command = Command("ssh-keygen", "-f", self.key[0], "-N", "")
+ command = Command("ssh-keygen", "-f", self.key[0], "-N", "", '-C', self.safe_name)
if key_type is not None:
command += Command("-t", key_type)
self._run_guest_command(command, silent=True)
@@ -773,6 +777,14 @@ class GuestTestcloud(tmt.GuestSsh):
self.config.COREOS_DATA = Template(COREOS_DATA).safe_substitute(
user_name=self.user, public_key=public_key)
+ print(f'{id(self.config)}')
+
+ print(f'{self.name} - before the barrier:' + '\n' + self.config.USER_DATA)
+
+ BARRIER.wait()
+
+ print(f'{self.name} - after the barrier:' + '\n' + self.config.USER_DATA)
+
def prepare_config(self) -> None:
""" Prepare common configuration """
import_testcloud() |
Let's try if it's better now!