-
Notifications
You must be signed in to change notification settings - Fork 115
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
HTTP Proxy customer cases update #14513
Conversation
trigger: test-robottelo |
PRT Result
|
@pytest.mark.tier3 | ||
def test_positive_environment_variable_unset_set(): | ||
"""Verify that satellite installer unsets and then sets back the environment variables | ||
|
||
:id: 596d753b-660b-49cb-b663-ff3cec439564 | ||
|
||
:BZ: 1886040 | ||
|
||
:customerscenario: true | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember this test, its related to old feature added in installer, which identifies and fails, if proxy is set on system, with this mentioned environment variable. So, I understand that this test is valid, but can I ask why are you considering removing it instead of automating it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered removing because the BZ says
3. Why does the customer need this? (List the business requirements here)
Since satellite maintain takes care of end to end upgrade, it should also have an additional check to unset an environment variable along with alerting the user.
The addition of this check will ensure that we can avoid the installer execution failure and fixing a potential issue at the pre-upgrade stage.
This coverage already exists here, so I considered it redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see it as redundant as the test you linked is being verified by foreman-maintain check which verifies it it exists in the environment, and here we use the installer to test, where behaviour here is different, installers unsets the variable while running and then sets it back when installer run completes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, my assumptions were following:
- The foreman-maintain health check (covered by the test linked above) checks if HTTP_PROXY env var is set and fails if it is.
- Satellite upgrade leverages the foremain-maintain health check as pre-upgrade check.
- If the pre-upgrade check fails (e.g. because of the HTTP_PROXY env var is set or otherwise), no upgrade nor satellite-installer is run. So the satellite-installer unset/set functionality is unreachable and thus appears redundant to me.
Is any of the assumptions wrong?
org=rhcloud_manifest_org.label, | ||
rhel_distro=f"rhel{rhel_contenthost.os_version.major}", | ||
) | ||
assert rhel_contenthost.execute('insights-client --register').status == 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
configure_rhai_client() will register this client to satellite, so here are we checking if it could be registered again to same satelllite? if not, can we remove this assertion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct, I think testing re-register won't harm.
1. Create HTTP Proxy. | ||
2. Set created proxy as "Default HTTP Proxy" in settings. | ||
3. Edit /etc/resolv.conf and comment out all entries so that | ||
satellite can not directly communicate outside. Ensure that | ||
NetworkManger won't change it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we're still following steps as part of setup with fixture, so can we keep this steps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, yes and no. Right now we don't do this kind of setup for any HTTP proxy testing, so this would be an exception. If we decide to hack the Satellite like this, I would rather do it for all tests through some fixture, not just for this particular case. It will require more testing for potential side-effects, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gauravtalreja1 PoC for the above #14754
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack pending other reviewer's comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! ack pending prior comments
This commit: - adds a case for insights client registration via HTTP proxy - removes old stub covered in foreman-maintain - updates http_proxy fixture to remove the proxy on teardown
aa2a952
to
de79b85
Compare
rebased |
trigger: test-robottelo |
PRT Result
|
PRT Result
|
This commit: - adds a case for insights client registration via HTTP proxy - removes old stub covered in foreman-maintain - updates http_proxy fixture to remove the proxy on teardown (cherry picked from commit c4507eb)
This commit: - adds a case for insights client registration via HTTP proxy - removes old stub covered in foreman-maintain - updates http_proxy fixture to remove the proxy on teardown (cherry picked from commit c4507eb)
This commit: - adds a case for insights client registration via HTTP proxy - removes old stub covered in foreman-maintain - updates http_proxy fixture to remove the proxy on teardown
This PR just addresses a few changes from the component eval
PRT test Cases example
trigger: test-robottelo
pytest: tests/foreman/cli/test_http_proxy.py -k insights