-
Notifications
You must be signed in to change notification settings - Fork 469
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
Create networking-console-plugin.md #1645
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,160 @@ | ||||||
--- | ||||||
title: networking-console-plugin | ||||||
authors: | ||||||
- "@upalatucci" | ||||||
reviewers: | ||||||
- "@orenc1" | ||||||
- "@zshi-redhat" | ||||||
- "@pcbailey" | ||||||
- "@metalice" | ||||||
- "@spadgett" | ||||||
- "@jhadvig" | ||||||
approvers: | ||||||
- "@dhellmann" | ||||||
api-approvers: | ||||||
- None | ||||||
creation-date: 2024-04-12 | ||||||
last-updated: 2024-04-12 | ||||||
tracking-link: | ||||||
- https://issues.redhat.com/browse/CONSOLE-3952 | ||||||
--- | ||||||
|
||||||
|
||||||
# Create console plugin for the networking section | ||||||
|
||||||
## Summary | ||||||
|
||||||
At present, several pages within the networking section of our console are defined within the console repository. | ||||||
However, working with the console repository has slowed down development and there are multiple motivations to convert static console plugins into dynamic ones described [here](https://github.com/spadgett/enhancements/blob/master/enhancements/console/dynamic-plugins.md#motivation). | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not a UI expert so could you please explain what is the difference between a static plugin and dynamic plugin from console perspective? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is the console repo: https://github.com/openshift/console
Static plugins are built within the console. Dynamic plugins instead are defined in separate repo (example) where they can define their workflow, dependenices and move faster in general. Those plugins CAN be built with a separate lifecycle and needs to be integrated by other operators to be part of openshift. The main benefit is not what you are mentioning but this:
Our experience with kubevirt-plugin proved that this works and we now move faster than ever. We are excited to do the same with networking, take responsibility of this section and add so much features There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, this is the way how the console plugins should be delivered, by the matching operator. Console itself can be hosting any more of plugins, matter of fact is that we are gradually try to move the plugins, both static and dynamic, from our repo because of various reasons, some of them also mentioned here. |
||||||
To address this, we propose relocating the relevant code to a separate repository named "networking-console-plugin" and integrating it into the cluster-networking-operator. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. might be a stupid question, but why specifically do we think this should live in CNO and not in https://github.com/kubevirt/cluster-network-addons-operator ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hei @tssurya. Right now the Networking console section is integrated with the console and in order to don't change the user experience, with this upgrade we would like to have this section delivered by default with openshift anyways. So if this addons-operator is delivered by default and it's not 'optional' I would leave the decision to the CNO team. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. CNO team and adds-on team are separate, my concern is around enabling yet another daemonset lifecycle management from CNO -> resources wise what's the increase/impact here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Console team is stretched with a lot of work and no one gets to maintain and develop new features for network UI for years so we're taking over this part. For us taking over means making the code future-proof and scalable fitting our standards. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes sure. We want this enabled in all places. So that when they access (or add in the future) the console, they can see all the Networking pages like Routes, Services, NADS and everything they already see now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The CNO needs to handle 4 resources:
(I'll add those details in the doc) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @upalatucci thanks for summary.
Here I would go with the third option, so the ownership is clearly defined. |
||||||
Having a different repository, separeta and define ownership between the plugin and the operator. | ||||||
My team (CNV UI team) is responsible on maintaining the source code and the console UI pages related to that. | ||||||
Previous to that, the networking section was maintained directly by the console team that right now is busy on lots of tasks. | ||||||
The pages that this plugin will handle are: Services, Route, Ingress, NetworkPolicy, and NetworkAttachmentDefinition pages for listing, creating, and editing those resources. | ||||||
|
||||||
The operator team should just make sure that the resources needed are installed in the cluster. | ||||||
|
||||||
|
||||||
|
||||||
|
||||||
## Motivation | ||||||
|
||||||
### User Stories | ||||||
|
||||||
N/A. For the end user the UI will be the same. The cluster admin will have the option to disable and enable the plugin but it's not relevant. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
I'm interested in this disable option, can you please expand more? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All the plugins installed in the cluster can be listed using this command
You can verify which plugins are enabled using this command
Disabling plugins means that the pages and features they provide will not be shown in the console. For example, this plugin defined an entire section in the console called 'Networking'. Disabling this plugin means that the user can no longer see this section in the console UI. |
||||||
|
||||||
|
||||||
### Goals: | ||||||
|
||||||
Enhanced Development Efficiency: By isolating networking console pages into a dedicated repository, developers can expedite development cycles and foster faster iterations, ultimately enhancing overall development efficiency. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this enhancement around have a new repo in OCP or integrating that with CNO or both? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the repo: https://github.com/openshift/networking-console-plugin In the CNO repo we need just to add the logic to install the plugin and handle some needed resources. |
||||||
|
||||||
Improved Maintainability: Segregating the networking console pages from the main console repository will simplify maintenance and testing efforts. | ||||||
|
||||||
Dedicated Team: Currently, backend networking features are progressing faster than the corresponding UI console pages. This change will make the CNV UI team directly responsible for enhancing pages and making future features easy to use and discover. | ||||||
|
||||||
### Non-Goals | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
## Proposal | ||||||
|
||||||
Proposal: | ||||||
|
||||||
To execute the migration of networking console pages to the "networking-console-plugin" repository and integrate them into the cluster-networking-operator, we propose the following steps: | ||||||
|
||||||
Create "networking-console-plugin" Repository (Done): Establish a new repository named "networking-console-plugin" to house the codebase for networking console pages. This repository will serve as the centralized location for all networking-related functionalities. | ||||||
|
||||||
Move Networking Console Pages (Done): Transfer relevant code files and resources from the console repository to the "networking-console-plugin" repository and refactor them. Ensure accurate migration of dependencies and configurations to maintain seamless functionality. | ||||||
|
||||||
Integration with Cluster-Networking-Operator: Modify the cluster-networking-operator to incorporate the networking console plugin as an operand. Update configurations and references accordingly to seamlessly integrate the networking pages with the operator. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what does this specifically entail? the workflow description seems empty? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. here is the pr: openshift/cluster-network-operator#2322 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Essentially, the integration of the networking-console-plugin in CNO entails creating and reconciling a few resources, and patching the This is very similar to what was done in |
||||||
This means that the operator should handle 4 resources: | ||||||
|
||||||
- Deployment (to deploy the docker file with all the plugin static files like js/css/svg/jpg) | ||||||
- ConfigMap (to add the nginx configuration to the deployment) | ||||||
- Service (to expose the static files) | ||||||
- ConsolePlugin (to let the console load the files and show the added pages) | ||||||
|
||||||
Incorporation into OpenShift Release Payload: Upon successful migration and integration, include the networking console plugin in the OpenShift release payload. This ensures the plugin is delivered by default with the console, providing users immediate access to enhanced networking functionalities. Cluster-networking-operator will enable the plugin by default. The Cluster-monitor-operator is doing the same thing with its plugin [here](https://github.com/openshift/cluster-monitoring-operator/blob/master/pkg/client/client.go#L1710). Until we have "Red Hat signed" plugins there is no other solution at the moment. | ||||||
|
||||||
We want to clearly state that the cluster-networking-operator team is not responsible of maintaining the plugin and we as a UI team will take responsability of those pages. | ||||||
|
||||||
|
||||||
### Workflow Description | ||||||
|
||||||
N/A | ||||||
|
||||||
### API Extensions | ||||||
N/A | ||||||
|
||||||
### Topology Considerations | ||||||
|
||||||
|
||||||
#### Hypershift / Hosted Control Planes | ||||||
|
||||||
N/A | ||||||
|
||||||
#### Standalone Clusters | ||||||
|
||||||
N/A | ||||||
|
||||||
#### Single-node Deployments or MicroShift | ||||||
|
||||||
N/A | ||||||
|
||||||
### Implementation Details/Notes/Constraints | ||||||
### Risks and Mitigations | ||||||
|
||||||
N/A | ||||||
|
||||||
### Drawbacks | ||||||
|
||||||
This means extra work in the beginning to integrate the operatand with the operator. | ||||||
|
||||||
## Test Plan | ||||||
|
||||||
E2e tests will run at every pr on the networking-console-plugin using prow just like other console dynamic plugins | ||||||
|
||||||
## Graduation Criteria | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
### Dev Preview -> Tech Preview | ||||||
|
||||||
N/A | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this dev preview aimed behind a feature gate? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No there is no feature gate There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we cannot merge features without feature gate in ocp.. please plan and add it in your enhancement There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We as UI team do not add ocp feautres. We just create UI to use them. We are moving part of the code and refactoring it. For the first version, the user will not even notice the difference. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Routes are part of ingress operator, so shouldn't that piece go there? cc @Miciah There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't want to split this section into such small pieces. It's not the best choice to move faster in the future. Creating a plugin repo with it's configuration and so on, is not that simple. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the plugin can even hide some pages if some functionalities are not installed in the cluster. For example if ingress operator is not installed we can hide routes if you think is the best solution. |
||||||
|
||||||
|
||||||
### Tech Preview -> GA | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
### Removing a deprecated feature | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
## Upgrade / Downgrade Strategy | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
## Version Skew Strategy | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
## Operational Aspects of API Extensions | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
## Support Procedures | ||||||
|
||||||
N/A | ||||||
|
||||||
|
||||||
## Alternatives | ||||||
|
||||||
Continue to work in the console using a static plugin. |
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.
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'm afraid to start a new naming convention here. Multiple plugins end with
console-plugin