Create networking-console-plugin.md #1645

upalatucci · 2024-06-17T16:15:01Z

open again #1606 pr

openshift-ci · 2024-06-17T16:18:32Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign danwinship for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

enhancements/network/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

jupierce · 2024-06-20T12:37:51Z

/retest

tssurya

Is this enhancement complete and ready for reviews? Many sections are empty, wondering if that was intentional

tssurya · 2024-07-10T17:37:56Z

enhancements/network/networking-console-plugin.md

+
+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). 
+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.


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 ?
what would be the plugin install's impact on resource consumption on the overall ocp cluster?
when we put this in CNO its going to be ON by default; are we sure we want console on all variants of sno,ocp,hcp,microshift etc?

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.

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?
infact I am not sure I am convinced networking console is a CNO thing.. perhaps it should stay in console? -> the reasoning provided is a "process reason -> let's move faster?" what is the user/functional impact/motivation here?
how does the upgrade design look like where things are currently part of console but now moving to CNO?
@upalatucci : thanks for taking the time to answer my questions; please add all this information into the enhancement so that the right context is being set (I think all the sections in the enhancements should be filled or a reasoning must be provided as to why its not relevant.).

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.
We have already received several requests but cannot keep adding things in an already busy and old console code.

when we put this in CNO its going to be ON by default; are we sure we want console on all variants of sno,ocp,hcp,microshift etc?

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.

what would be the plugin install's impact on resource consumption on the overall ocp cluster?

The CNO needs to handle 4 resources:

deployment (to deploy the docker image with static js/css/svg/jpg files)

configmap (nginx configuration)

service (expose the static files)

consoleplugin (to let the console load the static files)

(I'll add those details in the doc)

@upalatucci thanks for summary.
From what I read we have three choices how to move forward.

Place the plugin directly into CNO repo (plugin will be enabled and available by default), where Ugo's team will claim ownership over the plugin code.

Place the plugin in the CNaddonsO repo (plugin will need to be enabled manually, since the addons need to be installed manually)

Splitting the logic, by placing the plugin into a separate repo and source it by the CNO or CNaddosO, based on the default behaviour thats expected (similar to how the Virtualization Operator is delivering the kubevirt-plugin).

Here I would go with the third option, so the ownership is clearly defined.
I would suggest to tak to the kubevirt folks and check how thier operator is vendoring the plugin.

tssurya · 2024-07-10T17:38:35Z

enhancements/network/networking-console-plugin.md

+
+### 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. 


Suggested change

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.

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.

I'm interested in this disable option, can you please expand more?

All the plugins installed in the cluster can be listed using this command

oc get consoleplugins

You can verify which plugins are enabled using this command

oc get console.operator.openshift.io cluster -o jsonpath='{.spec.plugins}'

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.

tssurya · 2024-07-10T17:39:14Z

enhancements/network/networking-console-plugin.md

+
+### 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.


Is this enhancement around have a new repo in OCP or integrating that with CNO or both?

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.
CNO pr to integrate the plugin is here: openshift/cluster-network-operator#2322

tssurya · 2024-07-10T17:39:59Z

enhancements/network/networking-console-plugin.md

+
+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.


what does this specifically entail? the workflow description seems empty?

here is the pr: openshift/cluster-network-operator#2322

Essentially, the integration of the networking-console-plugin in CNO entails creating and reconciling a few resources, and patching the consoles.operator.openshift.io resource to enable it.

This is very similar to what was done in cluster-monitoring-operator to add the monitoring-plugin by default (the Observe section in the console).

tssurya · 2024-07-10T17:40:58Z

enhancements/network/networking-console-plugin.md

+
+### Dev Preview -> Tech Preview
+
+N/A


Is this dev preview aimed behind a feature gate?

No there is no feature gate

we cannot merge features without feature gate in ocp.. please plan and add it in your enhancement

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.
The features that I'm mentioning in this document are 'UI features' like 'clicking this button you'll create a Route'.

Routes are part of ingress operator, so shouldn't that piece go there? cc @Miciah

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.
I had to request a brew repo, prow configuration, jira configuration, the ART team to review everything. Several things do not justify pieces so small.
We already talk with the SVN team and they agreed to have this into their operator...

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.
But keep in mind that right now the user can see those pages either way

tssurya · 2024-07-10T17:43:13Z

enhancements/network/networking-console-plugin.md

+## 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). 


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?
Also when I read the provided link it states: "Static plugins can only be updated on the OpenShift release cadence. We want to enable plugin teams to move faster."
CNO also is the same.. we put in new features on release cadence, maybe I am missing something?

this is the console repo: https://github.com/openshift/console
In this repo you can find:

the main code that handle the console structure and provide an SDK for plugins

static plugins that using the SDK can the integrated into the console and add pages and functionality (example)

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 operator has to handle a couple of resources to make this work.

The main benefit is not what you are mentioning but this:

We already have a half-dozen teams contributing to console. We need to be able to scale as more teams contribute. This will be difficult if everyone is contributing to a single monorepo.

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

Our experience with kubevirt-plugin proved that this works and we now move faster than ever.

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.

jhadvig

Thanks @upalatucci for the proposal

jhadvig · 2024-07-26T10:34:45Z

enhancements/network/networking-console-plugin.md

@@ -0,0 +1,154 @@
+---
+title: networking-console-plugin


Suggested change

title: networking-console-plugin

title:console-networking-plugin

I'm afraid to start a new naming convention here. Multiple plugins end with console-plugin

jhadvig · 2024-07-26T10:41:04Z

enhancements/network/networking-console-plugin.md

+## 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). 


Our experience with kubevirt-plugin proved that this works and we now move faster than ever.

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.

jhadvig · 2024-07-26T10:46:55Z

enhancements/network/networking-console-plugin.md

+
+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). 
+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.


@upalatucci thanks for summary.
From what I read we have three choices how to move forward.

Place the plugin directly into CNO repo (plugin will be enabled and available by default), where Ugo's team will claim ownership over the plugin code.

Place the plugin in the CNaddonsO repo (plugin will need to be enabled manually, since the addons need to be installed manually)

Splitting the logic, by placing the plugin into a separate repo and source it by the CNO or CNaddosO, based on the default behaviour thats expected (similar to how the Virtualization Operator is delivering the kubevirt-plugin).

Here I would go with the third option, so the ownership is clearly defined.
I would suggest to tak to the kubevirt folks and check how thier operator is vendoring the plugin.

JacobTanenbaum · 2024-08-01T15:23:57Z

@upalatucci Could you add to this doc which team is responsible for maintaining the networking-console-plugin?

upalatucci · 2024-08-02T13:11:32Z

@JacobTanenbaum yes sure. I reinforce here and I'll do it in the doc that our team is responsible for this plugin @tnisan

openshift-ci · 2024-08-02T13:35:40Z

@upalatucci: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

upalatucci mentioned this pull request Jun 17, 2024

Create networking-console-plugin.md #1606

Closed

openshift-ci bot requested review from danwinship and dougbtv June 17, 2024 16:18

tssurya suggested changes Jul 10, 2024

View reviewed changes

upalatucci force-pushed the patch-1 branch 2 times, most recently from 558b59d to 4ca9e52 Compare July 11, 2024 09:33

jhadvig reviewed Jul 26, 2024

View reviewed changes

Create networking-console-plugin.md

477e7ef

upalatucci force-pushed the patch-1 branch from 4ca9e52 to 477e7ef Compare August 2, 2024 13:28


		### 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.


		### 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.


		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.

	title: networking-console-plugin
	title:console-networking-plugin

Create networking-console-plugin.md #1645

Are you sure you want to change the base?

Create networking-console-plugin.md #1645

Conversation

upalatucci commented Jun 17, 2024

openshift-ci bot commented Jun 17, 2024

jupierce commented Jun 20, 2024

tssurya left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tssurya Jul 11, 2024 • edited Loading

Choose a reason for hiding this comment

upalatucci Jul 11, 2024 • edited Loading

Choose a reason for hiding this comment

upalatucci Jul 11, 2024 • edited Loading

Choose a reason for hiding this comment

upalatucci Jul 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

upalatucci Jul 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tssurya Jul 10, 2024 • edited Loading

Choose a reason for hiding this comment

upalatucci Jul 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jhadvig left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JacobTanenbaum commented Aug 1, 2024

upalatucci commented Aug 2, 2024

openshift-ci bot commented Aug 2, 2024

tssurya Jul 11, 2024 •

edited

Loading

upalatucci Jul 11, 2024 •

edited

Loading

upalatucci Jul 11, 2024 •

edited

Loading

upalatucci Jul 11, 2024 •

edited

Loading

upalatucci Jul 25, 2024 •

edited

Loading

tssurya Jul 10, 2024 •

edited

Loading

upalatucci Jul 11, 2024 •

edited

Loading