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

Provide better error output for test_satellite_installation #17105

Merged
merged 3 commits into from
Dec 10, 2024

Conversation

ekohl
Copy link
Contributor

@ekohl ekohl commented Dec 6, 2024

Problem Statement

The current output of test_satellite_installation is useless. Because the output is so long, pytest truncates it which hides the relevant error.

Solution

As a first step, it does a trivial cleanup for readability. The next commit stops using len(x) == 0 and instead uses not x to assert there is no output. I haven't tested this, but I believe this allows pytest to skip a layer of output and hopefully also provide better output.

The real change is that it asserts the exit code of the installer to be 0 or 2. In practice I'd always expect 2, but 0 is also valid. See https://github.com/theforeman/kafo?tab=readme-ov-file#exit-code for more information. Since foreman-installer 3.8.0 (theforeman/foreman-installer@0d2fb67) it also displays structured output on the exact failure.

Related Issues

trigger: test-robottelo
pytest: tests/foreman/ui/test_contenthost.py -k 'test_satellite_installation'

ekohl added 3 commits December 6, 2024 14:37
Quoting PEP 20:

> Flat is better than nested.
This should help pytest to provide a better output.
If the installer failed, there's no point to continue. Since Foreman 3.8
it provides exactly which steps failed which is preferred over "parsing"
the log file.

Having an assertion in a fixture should result in the the test showing
up as ERROR.

Link: https://medium.com/opsops/pytest-fail-in-a-fixture-and-in-a-test-2122fab0564
Link: theforeman/foreman-installer@0d2fb67
@ekohl ekohl requested review from a team as code owners December 6, 2024 14:01
Copy link
Contributor Author

@ekohl ekohl 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 some issues with the installer_satellite fixture. I don't like that it always asserts success. Ideally speaking we would also test for failures. When I looked I could only find a single test that used this fixture, so perhaps it should be refactored to just present an empty machine and have the installer command be part of the test itself.

@@ -395,6 +394,9 @@ def installer_satellite(request):
).get_command(),
timeout='30m',
)
# exit code 0 means no changes, 2 means changes were applied succesfully
assert installer_result.status in (0, 2), installer_result.stdout
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I also debated assert 'There were errors detected during install not in installer_result.stdout` or similar.

Copy link
Member

Choose a reason for hiding this comment

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

Given we have the failed_when check based on satellite-installer RC, I wouldn't diverge from that in robottelo.

https://github.com/theforeman/foreman-operations-collection/blob/2bf0408ab1469908ac490878a91da388a4bbdba4/roles/installer/tasks/main.yml#L41

@rmynar rmynar added CherryPick PR needs CherryPick to previous branches AutoMerge_Cherry_Picked The cherrypicked PRs of master PR would be automerged if all checks passing 6.14.z Introduced in or relating directly to Satellite 6.14 6.15.z Introduced in or relating directly to Satellite 6.15 6.16.z Introduced in or relating directly to Satellite 6.16 labels Dec 9, 2024
Copy link
Member

@ogajduse ogajduse left a comment

Choose a reason for hiding this comment

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

Nice and clean, thank you!

When I looked I could only find a single test that used this fixture, so perhaps it should be refactored to just present an empty machine and have the installer command be part of the test itself.

From my point of view, this seems like a good idea. Would you be open to making the change sometime in the future?

@@ -395,6 +394,9 @@ def installer_satellite(request):
).get_command(),
timeout='30m',
)
# exit code 0 means no changes, 2 means changes were applied succesfully
assert installer_result.status in (0, 2), installer_result.stdout
Copy link
Member

Choose a reason for hiding this comment

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

Given we have the failed_when check based on satellite-installer RC, I wouldn't diverge from that in robottelo.

https://github.com/theforeman/foreman-operations-collection/blob/2bf0408ab1469908ac490878a91da388a4bbdba4/roles/installer/tasks/main.yml#L41

Copy link
Contributor

@rmynar rmynar left a comment

Choose a reason for hiding this comment

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

Looks good. I have just added some labels to cherrypick this into older branches.

The installer_satellite fixture was meant to be used within ipv6 installation test. But we decided to use different approach to test ipv4 and ipv6 installations. And the ipv6 stubbed testcases were removed recently - #16963

@ekohl
Copy link
Contributor Author

ekohl commented Dec 9, 2024

Would you be open to making the change sometime in the future?

I'm open to it, but I can't promise anything.

The installer_satellite fixture was meant to be used within ipv6 installation test. But we decided to use different approach to test ipv4 and ipv6 installations. And the ipv6 stubbed testcases were removed recently - #16963

Does that mean we can remove a lot of the fixture? Or really, I see there's also sat_ready_rhel and cap_ready_rhel. Is there a reason we can't use those for the test?

My confusion is mostly from various tests like test_positive_install_sat_with_katello_certs that largely duplicate the whole setup steps, but I don't feel comfortable restructuring the fixture organization.

@jameerpathan111 jameerpathan111 added the Stream Introduced in or relating directly to Satellite Stream/Master label Dec 10, 2024
@jameerpathan111
Copy link
Contributor

trigger: test-robottelo
pytest: tests/foreman/installer/test_installer.py -k test_satellite_installation

@Satellite-QE
Copy link
Collaborator

PRT Result

Build Number: 9571
Build Status: SUCCESS
PRT Comment: pytest tests/foreman/installer/test_installer.py -k test_satellite_installation --external-logging
Test Result : ========== 1 passed, 19 deselected, 32 warnings in 1493.58s (0:24:53) ==========

@Satellite-QE Satellite-QE added the PRT-Passed Indicates that latest PRT run is passed for the PR label Dec 10, 2024
@jameerpathan111
Copy link
Contributor

Does that mean we can remove a lot of the fixture? Or really, I see there's also sat_ready_rhel and cap_ready_rhel. Is there a reason we can't use those for the test?

IMO test code has been heavily changed and has become more complicated because of build_sanity. installer_satellite fixture was created for that purpose. It'd be quite a challenge to refactor it without touching sanity part. I'd rather leave the task of simplifying code to JPL team or at least make them involve. For now, let's merge this PR and we can discuss further refactoring tasks with JPL.

@ogajduse ogajduse merged commit c170b84 into SatelliteQE:master Dec 10, 2024
14 of 15 checks passed
github-actions bot pushed a commit that referenced this pull request Dec 10, 2024
github-actions bot pushed a commit that referenced this pull request Dec 10, 2024
@ekohl ekohl deleted the better-installer-sanity branch December 10, 2024 12:16
@ekohl
Copy link
Contributor Author

ekohl commented Dec 10, 2024

I'd rather leave the task of simplifying code to JPL team or at least make them involve. For now, let's merge this PR and we can discuss further refactoring tasks with JPL.

That makes sense to me. When I was thinking about it, I think the fixture does too many things but untangling requires much more thought.

@ogajduse
Copy link
Member

@ekohl Can you please backport your patch to the 6.14.z branch? ref. #17138

@ekohl
Copy link
Contributor Author

ekohl commented Dec 13, 2024

#17172

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.14.z Introduced in or relating directly to Satellite 6.14 6.15.z Introduced in or relating directly to Satellite 6.15 6.16.z Introduced in or relating directly to Satellite 6.16 AutoMerge_Cherry_Picked The cherrypicked PRs of master PR would be automerged if all checks passing CherryPick PR needs CherryPick to previous branches PRT-Passed Indicates that latest PRT run is passed for the PR Stream Introduced in or relating directly to Satellite Stream/Master
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants