Skip to content
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

add test inspector results into test library for nondestructive tests #19756

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jscotka
Copy link
Contributor

@jscotka jscotka commented Dec 18, 2023

Test of test inspector

else:
self.log(ADD, f"key:{key} ", new_data[key])

def _compare_string(self, old_data, new_data):

Check notice

Code scanning / CodeQL

Explicit returns mixed with implicit (fall through) returns Note

Mixing implicit and explicit returns may indicate an error as implicit returns always return None.
if old_data != new_data:
self.log(CHANGE, old_data, new_data)

def compare_multiline(self, old_data, new_data):

Check notice

Code scanning / CodeQL

Explicit returns mixed with implicit (fall through) returns Note

Mixing implicit and explicit returns may indicate an error as implicit returns always return None.
interface = item["ifname"]
adresses = list()
addrinfo_list = ["local", "prefixlen", "family", "label", "scope"]
for item in item["addr_info"]:

Check failure

Code scanning / CodeQL

Nested loops with same variable reused after inner loop body Error

Nested for statement
uses
loop variable 'item' of enclosing
for statement
.
interface = item["ifname"]
adresses = list()
addrinfo_list = ["local", "prefixlen", "family", "label", "scope"]
for item in item["addr_info"]:

Check notice

Code scanning / CodeQL

Nested loops with same variable Note

Nested for statement uses loop variable 'item' of enclosing
for statement
.
data = safe_dump(self.data)
elif self.store_type == PLAIN:
data = self.data
fd.write(data)

Check failure

Code scanning / CodeQL

Potentially uninitialized local variable Error

Local variable 'data' may be used before it is initialized.
@martinpitt
Copy link
Member

@jscotka that is a loooooot of code.. can we discuss the design of this first? However, tomorrow is the last workday for the remainder of the cockpit team this year, so perhaps start of January?

@martinpitt martinpitt marked this pull request as draft December 18, 2023 17:54
Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a quick look at the categories of information here. Thanks for this big effort, but I'm afraid this really isn't what's going to help us. The bits that surprise us are dynamic race conditions in event orders, udev, udisks, D-Bus signal orderings and so on. This kind of post-mortem data collection won't help us much there, I'm afraid, as there is almost never a doubt or difficulty about that.

Where useful, some tests gather/print specific and targeted extra information like here or here. But this is rare, mostly because in most cases of unexpected failures/races we can already see the visible end result of things going wrong in the journal and screenshot -- the hunt is about deducing (1) what's the root cause, and (2) creating a CLI reproducer for it for bug reporting (by far the hardest part).

As said, let's discuss this first what you had in mind, and for which failures this would have helped.

Thanks!

@@ -0,0 +1,40 @@
from pathlib import Path
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is never any doubt about what the config files in /etc contain. This is fixed in the images and our testlibs, we don't need that.

@@ -0,0 +1,52 @@
from testinsp.base import TestInspector
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also has never been doubtful. We know which interfaces are set up at any point in the test, and screenshots tell us their actual state.


class FirewallStatus(TestInspector):
store_type = YAML
_get_data_command = "firewall-cmd --list-all || true"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, this usually isn't a surprise. If "cockpit" service is not enabled, it's blatantly clear from the test output, and also our test setup explicitly enables it. For other services, the TestFirewall failures show the current state.


class ServiceInfo(TestInspector):
store_type = PLAIN
_get_data_command = "systemctl --type=service --state=running"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lot of data, and just overwhelming. The vast majority of services have nothing to do with a particular test case, and just add a lot of noise to the failure logs. This makes more sense for specific services which are unexpectedly running/not running, such as udisks.service failing in the storage tests. But we already see all of this in the journal attachments, so it's redundant.


class DiskInfo(TestInspector):
store_type = YAML
_get_data_command = "udisksctl dump"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This again falls into the "no surprise here" category. Our tests only ever work on scsi_debug or loop devices, their setup is in --verbose --trace and also in the journal. This is also redundant.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: There might very well be specific tests where this is unclear, but it should then be restricted to a particular test or at most storagelib.py. But this should be triggered by a failure where it would have helped. Every piece of information which we attach to a failure has a cost -- humans need to trawl through it and find the things that actually matter. Even then we usually only add it temporarily in a draft PR for examination (if it doesn't reproduce locally), and in most cases take it out again.

@martinpitt martinpitt added the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-test For doc/workflow changes, or experiments which don't need a full CI run,
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants