[Feature] Make Peering, Network, and Storage Fabrics Optional

[vicaya]

Appreciate the vision and code!

OTOH, it seems that for many use cases (at least for me), only the offloading feature is need and that the peering/network and storage fabric layers are mostly overhead. e.g., the IPAM of cooperative clusters could be planned ahead and that there exist more secure and efficient peering and network solutions without exposing public endpoints that need to be managed by Liqo. Data gravity is IMO a niche (anti-cloud) feature that's arguably not really aligned with the vision of moving workloads easily across clusters.

IMO, the control plane should focus on offloading and make it robust, which many could use immediately without the rest of the opinionated "features". I'd be delighted if it's already possible to install/deploy the offloading control plane only.

Thanks in advance for your advice/considerations!

[aleoli]

Hi @vicaya!

Thanks for your feedback! We are working toward better modularity to allow users to use single liqo features (as the offloading) without the need for the others.

Currently, you can turn off the networking by setting the values with helm accordingly:

networking:
  # -- Use the default Liqo network manager.
  internal: false
  # -- Reflect pod IPs and EnpointSlices to the remote clusters.
  reflectIPs: false

The first flag turns off the liqo network, while the second turns off the reflection of pod IPs and EndpointSlices to remote clusters; you can set them based on your needs.
The only requirement is to be able to reach the authentication endpoint for the first peering (this will likely removed in future releases), and the remote API Server.

I would appreciate suggestions about missing features or improvements in the offloading module. Thanks in advance!

[aleoli]

It is now possible with the liqo modules, see docs