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

Catch scc request timeout exception #63

Merged
merged 4 commits into from
Feb 19, 2024

Conversation

lcaparroz
Copy link
Collaborator

@lcaparroz lcaparroz commented Feb 9, 2024

Problem

When the SCC API times out during credentials validation, the module would break with an "Internal error" message displaying details about the Ruby exception.

Solution

Proper exception treatment was implemented, and now, a UI popup is displayed to the user, giving them the choice to either retry the validation or cancel the operation.

Testing

  • Added a new unit test: spec/rmt/wizard_scc_page_spec.rb.
  • Tested manually: the new behavior was tested according to the updated README instructions for a Docker setup, running the module against a localhost server to simulate a timeout.

Screenshots

1. [Existing] Initial screen when running yast2 rmt

image

2. [Existing] Screen after pressing Next to verify SCC Credentials and the request is taking too long to complete

image

3. [New] Popup dialog shown to the user when the request times out

The new UI was added on this step. This is the only change to UI.

image

4. [Existing] Screen if the user chooses to cancel the operation

image

This commit adds proper timeout exception treatment on the method
`RMT::WizardSCCPage#scc_credentials_valid?`:

* Before: an "Internal error" message would be shown if a request timed
  out when contacting SCC to validate the credentials.
* Now: a popup dialog will be shown, giving the user the choice to retry
  the request or cancel the operation.

Additionally, the request has been enriched with a proper "user agent"
to allow better debugging with SCC.
Copy link
Member

@lslezak lslezak 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 to me, just added two suggestions.

valid_credentials = nil
while valid_credentials.nil?
begin
res = Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |http| http.request(req) }
Copy link
Member

Choose a reason for hiding this comment

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

Just a minor suggestion:

Suggested change
res = Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |http| http.request(req) }
res = Net::HTTP.start(uri.host, uri.port, use_ssl: uri.is_a?(URI::HTTPS)) { |http| http.request(req) }

This is more robust as it will still work after you change the URL above to plain HTTP.

Copy link
Collaborator Author

@lcaparroz lcaparroz Feb 14, 2024

Choose a reason for hiding this comment

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

It's a nice enhancement, but since the URL is hard-coded, it will not be very helpful.

I wonder if it would be valuable for test and development purposes to have a way to configure the SCC URL (e.g.: env var), then this change would be very welcome. I had to manually change both the URL and the use_ssl flag whenever I tested it locally.

@@ -26,6 +26,8 @@ module RMT; end
class RMT::WizardSCCPage < Yast::Client
include ::UI::EventDispatcher

YAST_RMT_USER_AGENT = 'yast2-rmt'.freeze
Copy link
Member

@lslezak lslezak Feb 12, 2024

Choose a reason for hiding this comment

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

What about adding some version number to the agent string? Standard web browsers do that as well.

Non-working pseudocode:

YAST_RMT_USER_AGENT = "yast2-rmt/#{RMT::VERSION}".freeze

In theory this could allow to handle some corner cases or bugs in SMT on the server size. Or if the SCC changes the API it could fallback to old API for old versions...

Ideally this should not be needed but it would be nice to have this possibility as the last resort...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I created the constant module RMT::VERSION, added it to the user agent, and created a unit test to ensure it always matches the package version. Please check commit 89e919c.

@lcaparroz lcaparroz force-pushed the catch-scc-request-timeout-exception branch from 8c5cfa7 to 7d5fb82 Compare February 14, 2024 10:26
To enhance the 'User-Agent' used in the request headers, this commit
adds the module constant `RMT::Version`, which must always match the
package version specified in 'package/yast2-rmt.spec'.

Additionally, a unit test was created to ensure the versions always
match each other; if there is a version bump in packge spec file, the
RSpec tests will break if 'src/lib/rmt.rb' is not updated accordingly.
@lcaparroz lcaparroz force-pushed the catch-scc-request-timeout-exception branch from 7d5fb82 to 89e919c Compare February 14, 2024 10:30
2. Run the Docker container with access to the localhost network with the chosen distribution and version:

```shell
docker run --network host -v "$(pwd):/usr/src/app" -w "/usr/src/app" -it registry.opensuse.org/yast/sle-15/sp6/containers/yast-ruby sh
Copy link
Collaborator

Choose a reason for hiding this comment

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

Thank you very much Luis! This is awesome!

Copy link
Collaborator

@felixsch felixsch left a comment

Choose a reason for hiding this comment

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

lgtm 👍

image

How I reviewed this pull request:

  • Checked the awesome testing docs!
  • Run yast2-rmt against a local SCC:
    • Checked if the timeout works
    • Checked that everything works when no timeout occurs
  • Checked the suggestions and also the tests

As always, if you think I missed something I should test, please let me know!🚀

@lcaparroz lcaparroz merged commit 36baa4e into SLE-15-SP6 Feb 19, 2024
8 checks passed
@lcaparroz lcaparroz deleted the catch-scc-request-timeout-exception branch February 19, 2024 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants