-
Notifications
You must be signed in to change notification settings - Fork 197
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
Simplified Proxy Onboarding #9703
base: master
Are you sure you want to change the base?
Simplified Proxy Onboarding #9703
Conversation
👋 Hello! Thanks for contributing to our project. You can see the progress at the end of this page and at https://github.com/uyuni-project/uyuni/pull/9703/checks If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code. Reference tests: KNOWN ISSUES Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience. For more tips on troubleshooting, see the troubleshooting guide. Happy hacking! |
Suggested tests to cover this Pull Request
|
3ee4f96
to
ebc14ed
Compare
Be aware that you need to rebase master into your PR, as we had some changes in the GH workflows. |
ebc14ed
to
4e3d051
Compare
01af614
to
a0952ea
Compare
7029847
to
3275d4a
Compare
8ec6f22
to
1ae01d7
Compare
1ae01d7
to
84440a6
Compare
type SuccessType = boolean | undefined; | ||
|
||
export const ContainerConfigMessages = (success: SuccessType, messagesIn: React.ReactNode[], loading: boolean) => { | ||
if (success) { |
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 structure works, but feels a bit clunky with multiple branches all wrapped in a Messages
.
Since Messages
also returns null if there are no items, something along these lines would also work:
let items: MessageType[] = [];
if (success) {
items = [{
severity: "success",
text: <p>{t("Proxy configuration successfully applied.")}</p>,
}];
} else if ... { }
return <Messages items={items} />;
What do you think?
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.
Looks nice. As i based myself on the current proxy configuration solution I ended up neglecting that. ty!
@@ -0,0 +1,731 @@ | |||
import * as React from "react"; |
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.
The code here looks mostly fine, but I would recommend breaking this up into multiple files to make it easier to digest, right now it's a pretty big bite. One option would be types and enums in one file, utils like stuff around file readers in another, etc, but I don't have a strong preference for how to chop this up.
} | ||
}; | ||
|
||
const useDebounce = (callback: (...args: any) => any, timeoutMs: number) => |
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.
Would recommend putting this in web/html/src/utils/hooks
, and maybe also make it generic in case the types matter wherever we consume it later.
const useDebounce = (callback: (...args: any) => any, timeoutMs: number) => | |
const useDebounce = <T extends (...args: any) => any>(callback: T, timeoutMs: number) => |
Warning
This PR is a work in progress. While the core functionality is in place, there are still multiple scenarios to address and details to refine. This PR is intended to gather early feedback on the current implementation, considering the known issues (listed at the end).
What does this PR change?
This PR implements a new feature that aims to simplify the proxy onboarding process (following discussions at https://github.com/SUSE/spacewalk/issues/24680 and https://github.com/SUSE/spacewalk/issues/23714).
Currently, setting up a proxy involves the following steps: onboarding the minion, creating a proxy configuration file, installing Podman and mgrpxy (provided by uyuni tools), and finally running mgrpxy install.
For this initial feature iteration, our goal is to streamline the process by extending the existing web UI functionality (Container Based Proxy Configuration). Once the user fills in the necessary information in a form, the system will automatically set up the minion as a proxy with minimal manual intervention.
GUI diff
Documentation
TBD
Test coverage
TBD
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test
(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:
Before you merge
Check How to branch and merge properly!
Documentation Support
Pre-requisites
Note
Whether a minion can be converted to a proxy depends on the running manager:
Base Setup
If an onboarded minion meets the prerequisites to become a proxy, the first step is to go to the minion's Overview page. From there:
This action will make a new main tab, Proxy, visible.
Alternatively, the user can achieve the same result by clicking Convert to Proxy in the top-right corner of the Overview page.
The Proxy tab is intended to display data and provide operations related to the proxy. At this stage, it will only contain the form used to apply the proxy configurations to the minion.
WebUI Form
Note: All visible inputs are mandatory, except the Intermediate CAs.
Flow
Once the user fills in the form and it is valid, the "Apply" button will be enabled. Clicking it will trigger the following flow:
Known issues
Convert to Proxy button is not setting proxy entitlement;Applying a proxy configuration successfully isn't creating a proxy info (Convert to Proxy button is always visible);Previously saved registies/tags are not restored if toggling between Source or Registry Source options;When form is loaded and source is RPM, the Apply button is not enabled;Not meaningful fail messages back to the UI;Any updates on the form trigger validation over registry url fields (ie, repeated tag retrieval or catalog requests);