The enhancements from submariner-io

Developer oriented scale testing

We would like to create tooling that allows running multiple kind clusters in scale testing on one or more machines, and run scale testing to identify any issues.

Tasks:

Develop ability to run scale tests: make scale-test
Document tooling on the website
Run scale testing with the tool
Run longevity testing with the tool

Stretch goals:

Ability to generate load on the control plane

This tracker epic will also be updated with any issues identified during the scale & longevity testing

Get Submariner/OVN-Kubernetes Integration to a Production Ready State

Epic Description

OVN-Kubernetes is one of the two CNI's supported by RedHat Openshift, and will soon become the sole CNI for the Kubernetes distribution. Submariner supports the CNI via the OVN-Kubernetes specific NetworkPluginSyncer, however the design is more of a POC and currently non-functional with recent OVN-K versions. Many more steps need to be taken in order to ensure the integration is bug-free and ready for production environments, this epic will track the work that is needed to get the integration to such a state.

Acceptance Criteria

Submariner's ability to connect clusters utilizing the OVN-Kubernetes CNI is 100% functional with current OVN-K builds, and the correct CI infrastructure has been put into place in order to ensure the continued functionality of the integration.

Definition of Done (Checklist)

Work Items

Epic: Support OCP with submariner on VMWare

What would you like to be added:
Proposal is to fully support connecting multiple OCP clusters on VMWare using Submariner.

Why is this needed:
Aim of this proposal is to list and track steps needed to fill any gaps and allow full support for such deployments.

UPDATE
Investigations have confirmed that there is nothing that needs to be done to prepare cloud for VM Ware, in subctl or OCM. Expectation is that VMWare should work without any changes, except when using NSX which is for now outside scope of this EPIC.

Work Items

Based on results of investigations, only effort required is testing.

Add VMWare to Submariner Testday
Run QE on VMWare

Handle certificate rotation

Epic Description

We want to enable certificate rotation, especially for accessing the broker. Rotated certificates will need to be propagated somehow, or we’ll need to find some other (secure) way of authenticating and authorising access to the broker. This will have to include broker-info.subm files — we want subctl join to be possible throughout the lifetime of a broker.

Acceptance Criteria

Broker certificates are automatically rotated
Connected clusters suffer no disruption
subctl join continues working with broker-info.subm files produced during initial broker deployment (but not necessarily with an older version of subctl); any additional requirements are documented

Definition of Done (Checklist)

Work Items

Support Globalnet deployment in ACM/OCM

Epic Description

Currently, ACM/OCM only supports deploying Vanilla Submariner, and it's not possible to deploy Globalnet.
This EPIC is to track the individual tasks associated to implement Globalnet in ACM.

Along with this, we also want to address the remaining bits from the Globalnet 2.0 feature, primarily the metrics support and removing the dependency with the kube-proxy driver.

Acceptance Criteria

One should be able to deploy Globalnet with ACM with all the e2e tests passing.

Definition of Done (Checklist)

Work Items

The following are the individual work items for this feature.

Use ID scheme for enhancement proposals

Similar to how Kubernetes uses "KEP-####", we should give unique IDs to enhancement proposals so we can easily reference them elsewhere.

It would be obvious to use "SEP-####", and that's okay with me, but it does unfortunately also sometimes stand for "Somebody Else's Problem". 😅

https://www.urbandictionary.com/define.php?term=SEP

Broken link detected by CI

Periodic link aliveness CI detected a broken link. Please see the periodic job
results for details.

Support connecting multiple OCP clusters on ROSA using Submariner.

Epic Description

Support connecting multiple OCP clusters on ROSA using Submariner.
Why is this needed:
The aim of this proposal is to list and track steps needed to fill any gaps and allow full support for such deployments.

Acceptance Criteria

Should be able to prepare and deploy submariner in ROSA using subctl and cloud-prepare.

Definition of Done (Checklist)

Work Items

Documentation for deployments and removal using cloud-prepare and subctl

Extract broker syncer to it's own service

Epic Description

We need a service dedicated to syncing the broker information from the local cluster to the broker, and the broker info to the local cluster.

We have seen on scale testing that having the broker syncer inside the gateway causes issues to connectivity when there's a high enough scale.

Additionally, multiple projects (Submariner, Lighthouse) are using a specific broker syncer to sync over their resources.
From an architectural POV it would be simpler if there was a "broker syncer" service which can sync resources to/from the remote broker, and the local services would only consume local resources.
This decentralizes the information further, and decouples the services allowing the local services to easily keep working even if the broker is temporarily down.
In addition, this opens up possibilities of easy broker HA since the data can be easily replicated.

This can also benefit Axon as it decouples the control plane information dissemination from Submariner, allowing alternative methods to be used.

Acceptance Criteria

Submariner deployments work without any need for manual intervention
Upgrade from older Submariner deployments works seamlessly without any need for manual intervention
Lighthouse is supported
Globalnet is supported

Definition of Done (Checklist)

Work Items

Provide ARM64 support

Epic Description

We want to provide out-of-the-box support for ARM64. Submariner should just work on ARM64 nodes, with no special configuration by the administrator or end-user.

Acceptance Criteria

All the Submariner components can be deployed on ARM64 nodes
All the Submariner components work with each other regardless of individual nodes’ architectures (e.g. an x86 route agent connected to an ARM64 gateway, or failover from an x86 gateway to an ARM64)
Submariner gateways can connect to other-arch gateways

Definition of Done (Checklist)

Work Items

ensure all our dependencies are available on ARM64;
ensure we can build all our artifacts for ARM64;
ensure the images we push provide multi-arch manifests;
run tests on all the platforms we care about (assuming we have GHA support for them).

Depends on submariner-io/submariner#1772
Depends on submariner-io/lighthouse#694
Depends on submariner-io/submariner-operator#2021
Depends on submariner-io/subctl#66

Epic: descope the Submariner operator

Epic Description

The Submariner operator currently has wide-ranging privileges. It doesn’t need to be able to access anything outside the namespaces it manages, so this should be reduced. See https://hackmd.io/wVfLKpxtSN-P0n07Kx4J8Q for background.

Depends on submariner-io/submariner-operator#1105

RBAC generation will affect this, we should wait to have a better idea of that before starting work on designing this.

Acceptance Criteria

The operator is de-scoped, ideally with no ClusterRole, at minimum with justifications for every permission in its ClusterRole.

See also submariner-io/submariner-operator#1105 which overlaps with this; auto-generation should be used if the SDK supports it for namespace-scoped Roles.

Definition of Done (Checklist)

Work Items

[EPIC] OCM - Add option to run diagnose in UI

Epic Description

subctl diagnose is a CLI tool used to troubleshoot submariner deployments. But no such tools are available from the OCM UI. Add option in OCM UI to run diagnostics.

Refer submariner-io/submariner-operator#88

Acceptance Criteria

TBD

Definition of Done (Checklist)

Work Items

Need tools for synchronized actions across multiple git repos

What would you like to be added:
We need to either find or develop some tools to make actions across multiple repos in our org:

Create/Delete labels
Create/Delete milestones
Move tickets between project boards (eg when release finishes move remaining to backlog)
Update GHA versions (since were using SHAs)

Tooling could live under releases repo

Why is this needed:
We often need to do these manually which is a bit error prone and time consuming, would be better to have some tooling for this.

Submariner Globalnet Support with OVN-Kubernetes CNI

Epic Description

The current implementation of Globalnet Controller works with iptables based kubeproxy. We have to add support for clusters that use OVN as the network-plugin driver.

Acceptance Criteria

The Globalnet feature functions correctly when using Submariner with the OVN-Kubernetes CNI.

Definition of Done (Checklist)

Work Items

Epic: Hub controller for lighthouse

Epic Description

The goal of this epic is to implement ServiceImport merging.

Once an mcs-controller has been introduced, the reconciliation logic will be extended to address
the following open issues:

Mark conflicting ServiceExport objects with the ServiceExportConflict condition
Merge matching ServiceExport objects into a single ServiceImport object

Related enhancement proposal: #111

Acceptance Criteria

Lighthouse behaviour aligns with MCS specification:

Mark conflicting ServiceExport objects with the ServiceExportConflict condition
Merge matching ServiceExport objects into a single ServiceImport object

Definition of Done (Checklist)

Work Items

Epic: ImportPolicy for selective service import

Epic Description

This is a proposal to introduce policy CRDs to filter the ServiceImports that get added to
each cluster. The policy would primarily make it possible to limit what gets imported to a
cluster:

import all (the current behaviour)
import namespace foo
import named: [ foo:svc, ... ]
no import

The policy would additionally support namespace mapping so that ServiceImports can be added
into a different namepsace from the originating namespace in the event that there is a namespace
conflict between exporting and importing clusters.

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Consider implementing NAT-hole-punching techniques for all cable drivers in general

This would avoid the necessity of port mapping in a great deal of cases:

https://en.wikipedia.org/wiki/UDP_hole_punching

Once the UDP hole is punched (if the router would allow that, of course),
then we can advertise that port as the port to be used for NATT discovery or UDP traffic.

Epic: Move subctl to its own repo

Epic Description

subctl, soon to be a library itself, should be moved out of submariner-operator repo to its own repo. Everything specific to the subctl is moved to the subctl repo. Operator repo depends on the subctl repo. Operator repo should contain things that the operator framework generates/ needs. This is an alternative to the previous proposal of moving bundles out of the operator repo.

Pros:

both subctl and operator require different set of dependencies which might conflict will improving subctl/operator. For eg, subctl can't be go install-ed currently because the operator dependencies don't allow it.
operator framework upgrades would be simpler.
its logically correct to separate operator and a library as they are 2 different deliverables and provides different ways to install Submariner.
Testing criterias are also different. We don't need subctl related GHAs for operator and vice versa.
Development approach is also different. 1 is a CLI and another is a framework.
submariner-addon integration might be simplified.

Cons:

A new repo to maintain
Might add a new phase to the automated release process

Acceptance Criteria

All of the subctl related code/GHAs are out of operator repo and in the new subctl repo.

Definition of Done (Checklist)

Work Items

Depends on #114

Create a new subctl repository and copy all the contents from submariner-operator repository.

External dependencies

Add subctl dependency in submariner-addon.

E2E checks should abort on the first failure

Currently, E2E tests run the full test suite, even when tests are failing. The failures often show up as time-outs, and a failing test suite thus takes a very long time; but in most cases, we’re only interested in whether the tests pass or fail, not the details of the failure (after the first one). This is particularly visible with flaky tests and causes significant delays in the release process.

We should add an option to abort on the first failure, and enable it when run from GHAs.

This would involve:

Providing some way of controlling whether make e2e runs all tests or aborts on the first failure (at the Ginkgo level); this should default to run all tests, to preserve existing behaviour for local invocations.
Setting up all the E2E GHAs to run make e2e with the setting to abort on first failure; this might involve changes in all projects.

This shouldn’t affect the GHA test matrices at all — we still want to run E2E in all desired configurations, the only change is that within each run, the first failure should abort that run.

Automated unjoin/uninstall

Epic Description

Add support to automatically "unjoin" a previously connected cluster by deleting/uninstalling all the Submariner-related components and removing dataplane rules programmed on the route agent and gateway nodes.

This is a common request from users. A manual process is documented here.

The uninstall process should be able to be initiated via a subctl command and also via the Submariner ACM add-on.

For dataplane cleanup, this blog describes how to run a one-time task on each node using a DaemonSet with an init container to run the task. We can create cleanup DaemonSets corresponding to each component (route agent, gateway engine etc). We can reuse the same images and pass an UNINSTALL environment variable to initiate the cleanup.

The tricky part is how to invoke the cleanup DaemonSets. The logical place would be from the Operator controller. We could put a finalizer on the Submariner resource and, when it's being deleted, delete the normal component DaemonSets and create the cleanup DaemonSets. After the cleanup DaemonSets have completed (ie are ready), remove the finalizer and let deletion of the Submariner resource proceed.

If cleanup fails for a component, the DaemonSet init container pod would return a non-zero exit code causing K8s to restart the pod. The Operator controller can wait a certain amount of time, like 2 min, for a cleanup DaemonSet to be ready. After that time it’s reasonable to assume the error isn’t transient so the Operator controller can remove the finalizer and let deletion of the Submariner resource proceed. It could leave the cleanup DaemonSet so the user can inspect the DaemonSet status to see what failed. Or it could delete the DaemonSet and we could create a K8s Event to report the failure, either from the Operator or the failing pod. In subctl, after Submariner is deleted, we can report the failure to the user. Any cleanup DaemonSet that failed will eventually get deleted along with the namespace regardless.

The one potential downside with this approach is if the Operator pod is deleted first and thus the controller is never triggered. This would also leave the finalizer and prevent the Submariner resource from being deleted. But we can document the proper sequence.

Acceptance Criteria

Invoking the uninstall process should remove all Submariner-related components and artifacts in the cluster.

Definition of Done (Checklist)

Work Items

Related Issues

Add support for finer-grained cluster connectivity options

Submariner currently assumes full mesh by default, and provision VPN connections between all participating clusters. For some use cases, it makes sense to offer finer-grained connectivity options. This could also improve overall scalability/state maintained, for those cases in which full mesh is not required.

Add support for Kube-OVN.

Epic Description

Ovn-kubernetes is not so convenient to use. Please consider supporting Kube-OVN.

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic: Simultaneous multiple cable support

Epic Description

Submariner currently offers three cable drivers: VXLAN, IPSec or wireguard. However only one of these cable drivers
is enabled across all the clusters in a ClusterSet; That is all clusters that join a broker must use the same cable
driver. The goal of this proposal is to extend the current model to support the selection of different cable types
between connected clusters. For example, an IPSec cable between public and private clouds but a VXLAN cable between
the clusters in the same cloud.

More details can be found here: #110

Acceptance Criteria

Multiple cables can be deployed with Submariner Gateways

Definition of Done (Checklist)

Work Items

Rework kubeconfig/kubecontext handling in subctl

The various subctl commands support a mixture of KUBECONFIG environment variables, --kubeconfig flags, --kubecontext flags, kubeconfig files etc.

We should make this consistent, ideally using clientcmd’s tools to handle kubeconfig. skitt/submariner-operator#23 has an old attempt at this, using https://pkg.go.dev/k8s.io/[email protected]/tools/clientcmd#BindOverrideFlags to provide access to all the features supported by clientcmd (see kubectl options).

For commands using a single context, all the following should work, with kubeconfigs containing one or more clusters and/or contexts (this uses a kube prefix when setting up clientcmd):

# Use the default context in the kubeconfig
KUBECONFIG=/path/to/kubeconfig subctl foo
subctl foo --kubeconfig /path/to/kubeconfig
subctl --kubeconfig /path/to/kubeconfig foo

# Use the specified context from the kubeconfig
KUBECONFIG=/path/to/kubeconfig subctl foo --kubecontext bar
subctl foo --kubeconfig /path/to/kubeconfig --kubecontext bar
subctl --kubeconfig /path/to/kubeconfig --kubecontext bar foo

For commands using multiple contexts, the prefixes should make the purpose of each context clear, using appropriate prefixes when setting up clientcmd:

KUBECONFIG=/path/to/kubeconfig subctl benchmark latency --fromcontext foo --tocontext bar
subctl benchmark latency --kubeconfig /path/to/kubeconfig --fromcontext foo --tocontext bar

--kubeconfig is preserved as-is, since users can use a single file combining all their contexts. However such commands should also support separate kubeconfigs:

subctl benchmark latency --fromconfig /path/to/fromconfig --toconfig /path/to/toconfig

clientcmd doesn’t handle --kubeconfig itself, that needs to be handled by subctl.

This enhancement should also include a test suite covering all the different possibilities. As far as possible, the 0.12 options should keep their existing behaviour, and be marked for deprecation; they will be removed after 0.13.

This would subsume submariner-io/subctl#49

[EPIC] Debuggability and Troubleshooting support in OCM

name: Debuggability and Troubleshooting
about: Improving debuggability and troubleshooting for submariner deplyments in general, OCM in particular
labels: epic

Epic Description

Current documentation on Sumariner.io - Troubleshooting docs covers the basic manual steps and how to run subctl diagnose and gather. What more needs to be done? Aim is to make it easy for support teams to troubleshoot and resolve the problems, or capture relevant information if unable to resolve.

Acceptance Criteria

TBD

Definition of Done (Checklist)

Work Items

Add support for full node mesh

Full node mesh can be support with the wireguard VPN implementation.
Full node mesh adds the following:

maximum theoretical bandwidth exploitation
best possible resilience to node failure, in fact with n active gateways (#34 ) a node failure causes a drop in bandwidth of 1/n. But with full node mesh a node failure causes a drop in bandwidth of zero as the only workload that is impacted by it is also failed.

Support connecting multiple OCP clusters on RHOS using Submariner

Epic Description

Support connecting multiple OCP clusters on RHOS using Submariner.
Why is this needed:
The aim of this proposal is to list and track steps needed to fill any gaps and allow full support for such deployments.

Acceptance Criteria

Should be able to prepare and deploy submariner in RHOS using subctl and cloud-prepare.

Definition of Done (Checklist)

Work Items

consider a tailscale cable driver (wireguard under the hood)

Using a subnet router would theoretically make it possible:

https://tailscale.com/kb/1019/subnets/

It's a managed wireguard on steroids, which would allow connecting also to existing legacy workloads
with ease.

It supports HTTP relay via their cloud servers for cases where NAT traversal is impossible, as well as
NAT hole punching techniques, etc...

Make broker objects expirable (auto-cleanup)

See [1] for reference.

Broker Endpoints and cluster could expire if the timestamp is not updated in T, while submariner
would update the objects every T/2 time.

Alternatively, instead of auto-cleanup, this could be an admin triggered action on the broker, to avoid
for example downtime to cluster who can't contact the broker temporarily.

Cleanup of local copies should not happen if the broker is unreachable to avoid dataplane downtime
while the broker is down.

[1] https://github.com/submariner-io/submariner/blob/devel/pkg/cableengine/syncer/syncer.go#L142

Improve integration with submariner-addon

Epic Description

Submariner addon should use submariner operator to manage submariner deployment on managed clusters. This allows for reusing of operator, automated management using operator and a single point of development efforts.

Acceptance Criteria

addon uses operator to deploy broker and submariner on hub and spokes.

Definition of Done (Checklist)

Work Items

Depends on submariner-io/submariner-operator#1040

Epic: Support OCP with submariner on Azure

What would you like to be added:
Proposal is to fully support connecting multiple OCP clusters on Azure using Submariner.

Why is this needed:
Aim of this proposal is to list and track steps needed to fill any gaps and allow full support for such deployments.

Work Items

Test and confirm manual steps to get Azure with submariner working
Add API in cloud-prepare to create and return client with Azure credentials
Add support for load balancer mode
submariner-io/cloud-prepare/issues/289
submariner-io/submariner-website#766
submariner-io/subctl#17
submariner-io/submariner-operator#1762
submariner-io/submariner-operator#1763
submariner-io/cloud-prepare#22

subctl show command to return non-zero exit code on failed resource

Does subctl show command returns non-zero exit code, if there's a missing/failed resource (e.g connections, networks, gateways, etc.) ?

If not, can you add this feature ?

[EPIC] Add option to gather submariner logs from OCM UI

Epic Description

subctl gather is a CLI tool used to gather logs and other data from submariner deployments. But no such tools are available from the OCM UI. Add option in OCM UI to run gather logs.

Refer #88

Acceptance Criteria

TBD

Definition of Done (Checklist)

Work Items

Addon - Run subctl gather Job on the cluster
UI - Add option to run gather from
UI - Add option to collect logs from a gather run
UI - Provide option to run gather after a fail diagnostics when running diagnostics

Broken link detected by CI

Periodic link aliveness CI detected a broken link. Please see the periodic job
results for details.

Epic: New Cable Driver protocols

Epic Description

The goal of this Epic is to enable a number of new features for Submariner Cable Drivers:

additional cable driver encapsulation protocols, including: IP in IP and GRE. Enabling these encapsulation protocols could allow for performance improvements over the current configuration.
Enabling IPSec transport mode - coupled with VXLAN, GRE or IP in IP.
It should be possible to do finer grained configurations for any of these cable drivers, for example in the case of IPSec, selecting the encryption algorithm, or for VXLAN selecting the UDP port (separately to the NAT port)...

Acceptance Criteria

New Cable Drivers are functional and deployable with the Submariner Gateways.

Definition of Done (Checklist)

Work Items

Cluster already has GlobalCIDR allocated: 169.254

Submariner support for load-balancer mode

Epic Description

Submariner load-balancer support

Currently, the load-balancer mode is an experimental feature in Submariner and is not well tested across various public and onPrem clusters. This EPIC is to understand the load-balancer implementations across AWS and GCP clouds to start with, finding any gaps and also its implications on HA-failover times.

Acceptance Criteria

Identify and where applicable fix the missing gaps in order to make load balancer a supported feature.

Work Items

The following are the individual work items for this feature.

Epic: Restructure/refactor submariner-operator repo

Epic Description

This will ensure that submariner-operator repo structure follows go standards and is optimised.

Acceptance Criteria

submariner-operator code is as much optimised and modular as possible.

Definition of Done (Checklist)

Code complete
~~[ ] Relevant metrics added~~
The acceptance criteria met
Unit/e2e test added & pass
CI jobs pass
~~[ ] Deployed using cloud-prepare+subctl~~
~~[ ] Deployed using ACM/OCM addon~~
~~[ ] Deploy using Helm~~
~~[ ] Deployed on supported platforms (for e.g kind, OCP on AWS, OCP on GCP)~~
Run subctl verify, diagnose and gather
~~[ ] Uninstall~~
~~[ ] Troubleshooting (gather/diagnose) added~~
~~[ ] Documentation added~~
~~[ ] Release notes added~~

Work Items

Make subctl a library Depends on submariner-io/submariner-operator#1329

Move reporter API from submariner-operator to admiral

What would you like to be added:

The reporter API is generic so move it to admiral.

Why is this needed:

This will allow the API to be used by other projects, specifically in cloud-prepare to replace a similar API.

[EPIC] Support for VPC Peering

What would you like to be added:
Proposal is to add support for VPC Peering between clusters deployed with same cloud provider.

Why is this needed:
When all cluster are deployed within the same cloud provider, VPC Peering provides secure networking between them. In such scenario one can use VxLan Cable driver for better performance without the IPSec overhead.

Work Items

Epic: Support OCP with submariner on IBM Cloud

What would you like to be added:
Proposal is to fully support connecting multiple OCP clusters on IBM Cloud using Submariner.

Why is this needed:
Aim of this proposal is to list and track steps needed to fill any gaps and allow full support for such deployments.

Work Items

Epic: Add support for multiple active gateways

multiple active gateways can increase the bandwidth. Some cloud provider have limited instance-to-instance bandwidth between regions, so this feature is an enabler for all throughput-sensitive workloads.

Enhancement document: #69

Epic: Debuggability improvements

Epic Description

Improve current troubleshooting documentation on Sumariner.io - Troubleshooting docs
Aim is to make it easy for support teams to troubleshoot and resolve the problems, or capture relevant information if unable to resolve.

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Broken link detected by CI

Periodic link aliveness CI detected a broken link. Please see the periodic job
results for details.

Add support for boringtun or wireguard-go in wireguard when kernel module is not available

https://github.com/cloudflare/boringtun It's a rust based, very performant implementation of wireguard.

https://github.com/WireGuard/wireguard-go is a go-based inplementation (performance to be checked)

Epic: rebuild the Submariner operator using current best practices

Epic Description

The operator was built using an old version of the Operator SDK. This causes a number of problems:

our code (in particular, metrics setup) relies on an old version of the Operator framework, which is incompatible with current versions of the Kubernetes libraries
we’re missing out on features supported by newer versions of the SDK (such as healthchecks)

We need to upgrade our operator to use the current Operator SDK, following the migration guide.

Depends on #89

Acceptance Criteria

The operator’s Operator framework dependencies are up-to-date, and all tests pass.

Definition of Done (Checklist)

Code complete
The acceptance criteria met
Unit/e2e test added & pass
CI jobs pass
Deployed using cloud-prepare+subctl
Deployed using ACM/OCM addon
Deploy using Helm
Deployed on supported platforms (for e.g kind, OCP on AWS, OCP on GCP)
Run subctl verify, diagnose and gather
~~[ ] Uninstall~~
~~[ ] Troubleshooting (gather/diagnose) added~~
~~[ ] Documentation added~~
~~[ ] Release notes added~~

Work Items

An operator was written from scratch following the official operator tutorial. The code was pushed on a fork as a PR. This PR was then used as a reference to make required changes.

The operator-sdk version is upgraded to 1.23.0. Migration guide was followed to pin versions for dependencies.

Depends on submariner-io/submariner-operator#2158
Update versions of various dependencies used
1. Depends on submariner-io/submariner-operator#2210
2. Depends on submariner-io/submariner-operator#2179
Depends on submariner-io/submariner-operator#2178
Depends on submariner-io/submariner-operator#2211
Depends on submariner-io/submariner-operator#2204
Depends on submariner-io/submariner-operator#2199
Depends on submariner-io/submariner-operator#2180
Depends on submariner-io/submariner-operator#2230
Update bundle in `operatorHub'(https://github.com/k8s-operatorhub/community-operators)
and here? https://github.com/redhat-openshift-ecosystem/community-operators-prod/tree/main/operators

[EPIC]: Connection status in OCM UI

Epic Description

Currently OCM UI doesn't show connection status in its own UI. It shows up as part of ManagedClusterAddOn status. It is not very intuitive for user to know which cluster connections are in connecting or error states. With topology view available in OCM 2.6, it should be used to display multicluster connection information to user.

Refer #88

Acceptance Criteria

Definition of Done (Checklist)

Work Items

OCM - Add Connection Status to UI
- Add ConnectionStatus CRD or such a field to SubmarinerConfig Status in submariner addon.
- https://github.com/stolostron/backlog/issues/19294

Dependencies

This requires topology view to be available in OCM UI. Also requires some design discussions with UI team on how to model ConnectionStatus CRD so it can be used by UI in a scaleable way.

Epic: CNCF Incubation/Graduation, CII Silver/Gold

Epic Description

Prepare to apply for CNCF Incubation. Use CNCF Graduation and CII Silver/Gold as guidance for exceeding Incubation minimums and preparing for Graduating in less than two years from Incubating (per requirements).

Acceptance Criteria

CNCF Sandbox

Trademarks: transfer any trademark and logo mark assets over to the LF - https://github.com/cncf/foundation/tree/master/agreements has agreements
- Chris sent another round of emails to try to move this forward. cncf/toc#649 (comment)

Support different cable drivers/settings inside the same supercluster

What would you like to be added:

Support for different cable drivers inside the same supercluster.

Why is this needed:

Once we start supporting cable drivers with meaningfully different features (sorry if I’m insulting any existing cable driver), e.g. submariner-io/submariner#674, various scenarios involve mixing cable drivers. For example, a supercluster could contain three clusters, one of which should only be connected to using encrypted connections, but two of which may be connected to using unencrypted connections (because they’re connected by a private link). So we’d have three connections, one unencrypted and two encrypted, presumably using different cable drivers.

submariner-io / enhancements Goto Github PK

enhancements's People

Contributors

Stargazers

Watchers

Forkers

enhancements's Issues

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

On subctl repository

On submariner-operator repository

On get.submariner.io repository

On submariner-website repository

Release process

External dependencies

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Related Issues

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

Definition of Done (Checklist)

Work Items

Epic Description

Acceptance Criteria

On `subctl` repository

On `submariner-operator` repository

On `get.submariner.io` repository

On `submariner-website` repository