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.

Sign up for GitHub

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

Jump to bottom

Create networking-console-plugin.md #1645

Closed
wants to merge 1 commit into from
Closed

Create networking-console-plugin.md #1645

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
160 changes: 160 additions & 0 deletions enhancements/network/networking-console-plugin.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,160 @@
---
title: networking-console-plugin
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
title: networking-console-plugin
title:console-networking-plugin

Copy link
Author

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

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).
Copy link
Contributor

@tssurya tssurya Jul 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The 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?
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?

Copy link
Author

@upalatucci upalatucci Jul 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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 ?
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?

Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Contributor

@tssurya tssurya Jul 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

The 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?
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.).

Copy link
Author

@upalatucci upalatucci Jul 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Copy link
Author

@upalatucci upalatucci Jul 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

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.

Copy link
Author

@upalatucci upalatucci Jul 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

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)

Copy link
Member

Choose a reason for hiding this comment

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

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

  1. 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.
  2. Place the plugin in the CNaddonsO repo (plugin will need to be enabled manually, since the addons need to be installed manually)
  3. 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.

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.
Copy link
Contributor

Choose a reason for hiding this comment

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

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?

Copy link
Author

Choose a reason for hiding this comment

The 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

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.



### 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Author

Choose a reason for hiding this comment

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


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.
Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Author

Choose a reason for hiding this comment

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

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

Copy link

Choose a reason for hiding this comment

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

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
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this dev preview aimed behind a feature gate?

Copy link
Author

Choose a reason for hiding this comment

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

No there is no feature gate

Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

The 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

Copy link
Author

@upalatucci upalatucci Jul 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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



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