Enhancement/liqo v1.0.0

[rmedina97]

Hello everyone,

With this PR we are updating the Liqo version from v0.10.3 to v1.0.0

What changes will you see?
TLDR: everything will be exactly the same as before, except for the liqoctl tool version, which must now be at least v1.0.0.

Long answer: The integration of the Liqo version mainly affected the peering feature of the Virtual Fabric Manager (part of the Rear Manager). All new resources to create a manual peering in Liqo v1.0.0 are inside this function, but at the end you will always have the VPN channel through Wireguard, the foreign clusters and most important: the namespace offloadings and the virtual nodes.
The breaking change, user side, is to use the version of the liqoctl tool updated to v1.0.0 and the new commands to check the liqo peering "liqoctl info peer" (not compatible with old liqoctl versions).

What if you use low-level Liqo resources directly?
If you use resources such as namespace offloads or interact with virtual nodes through automated processes, you need to update your Liqo dependency to v1.0.0. Fortunately, these resources haven't changed much, but be aware of changes in labels or specific fields in the specs and status of these resources.

No problem if you use the liqoctl tool to offload the namespace and interact with Liqo, everything should be pretty much the same.

Breaking changes in the Fluidos node
Setup script
The setup script for testing the node within KinD has been updated to use the new Liqo version, it should detect if you have the liqoctl v1.0.0 installed locally, otherwise it will automatically install it in a tmp folder (so as not to damage or replace your currently installed stable version of liqoctl).
If you want to use the liqoctl downloaded, compiled and used by the script, you can find it (temporarily) in /tmp/liqo/liqoctl.

Foreign Cluster Interaction
Previously the foreign cluster was the starting point of our peering function, it was enough. In the new version of Liqo, the foreign cluster is something that is automatically created by Liqo once all the various steps of manual peering have been completed (network setup, authentication, offloading). The allocation controller still watches the resources of the foreign cluster, but only as an informer about the status of the peering.

Liqo Peering Phases
The Liqo v1.0.0 manual peering has three main phases to set up peering. I won't go into detail, but roughly the same steps are reproduced in the Virtual Fabric Manager module, and they are performed in a similar way, trying to use the Liqo library as much as possible.

How peering is done
The Liqo v1.0.0 does not support the old way of creating a token and exchanging it with the consumer, now they need to exchange a kubeconfig. In the same way, we reproduce this step, creating a kubeconfig, with the minimum permissions for the consumer to just create the various Liqo resources to establish peering, both locally and remotely. This is something that can definitely be improved (by carefully removing the service account generated once the peering has been established, exchanging only the data to create the various resources on both clusters, etc.), but with this first integration I evaluated to just keep it simple enough to test if Liqo v1.0.0 was suitable inside the Fluidos node.

This data replaces the token previously exchanged via REAR to perform this kubeconfig exchange. Therefore, the field name and meaning may have changed (only the token). However, the protocol and its workflow are exactly the same as before.

Removing the GRPC server
Previously we had the GRPC server running inside the Rear Controller component, which was responsible for telling Liqo the exact amount of resources to allocate for a given peering. This component is no longer supported because in the offloading phase you create a custom resource slice (Liqo resource) that owns this data. In this version of the integration, I decided to just write the amount of resources to look in the contract, but the resource slice needs to be created by the consumer, so the one who buys the resources. An experienced user can simply edit these resources applied by the rear manager in the peering phase and get more than what was agreed.
This can be fixed by editing the resource slice to a custom "class" (spec of the resource slice) and on the provider side, a controller can watch for this resource slice on specific class and populate its resources according to the contract that the provider owns by its side.

So this is a known issue, with an ideal solution to be implemented, but at the moment the purpose of this PR is to test the Liqo v1.0.0 integration.

I hope this contribution will be appreciated and tested. Once tested through this specific branch, I would suggest to move it to the main branch and release it carefully, maybe through a release candidate first to check if everything works.

Feel free to give us feedback.

Thanks a lot!

Andrea, Riccardo

[fluidos-bot]

The generated artifacts appear to be out-of-date.

Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:

make generate

Here it is an excerpt of the diff:

[fluidos-bot]

The generated artifacts appear to be out-of-date.

Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:

make generate

Here it is an excerpt of the diff:

[fluidos-bot]

The generated artifacts appear to be out-of-date.

Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:

make generate

Here it is an excerpt of the diff:

[fluidos-bot]

The generated artifacts appear to be out-of-date.

Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:

make generate

Here it is an excerpt of the diff:

[fluidos-bot]

The generated artifacts appear to be out-of-date.

Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:

make generate

Here it is an excerpt of the diff:

[fluidos-bot]

The generated artifacts appear to be out-of-date.

Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:

make generate

Here it is an excerpt of the diff:

diff --git a/apis/network/v1alpha1/zz_generated.deepcopy.go b/apis/network/v1alpha1/zz_generated.deepcopy.go%0Aindex 273f12f..6cbebfb 100644%0A--- a/apis/network/v1alpha1/zz_generated.deepcopy.go%0A+++ b/apis/network/v1alpha1/zz_generated.deepcopy.go%0A@@ -19,7 +19,6 @@%0A package v1alpha1%0A %0A import (%0A-	"k8s.io/api/core/v1"%0A 	runtime "k8s.io/apimachinery/pkg/runtime"%0A )%0A %0A@@ -28,7 +27,7 @@ func (in *Broker) DeepCopyInto(out *Broker) {%0A 	*out = *in%0A 	out.TypeMeta = in.TypeMeta%0A 	in.ObjectMeta.DeepCopyInto(&out.ObjectMeta)%0A-	in.Spec.DeepCopyInto(&out.Spec)%0A+	out.Spec = in.Spec%0A 	out.Status = in.Status%0A }%0A %0A@@ -85,16 +84,6 @@ func (in *BrokerList) DeepCopyObject() runtime.Object {%0A // DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.%0A func (in *BrokerSpec) DeepCopyInto(out *BrokerSpec) {%0A 	*out = *in%0A-	if in.ClCert != nil {%0A-		in, out := &in.ClCert, &out.ClCert%0A-		*out = new(v1.Secret)%0A-		(*in).DeepCopyInto(*out)%0A-	}%0A-	if in.CaCert != nil {%0A-		in, out := &in.CaCert, &out.CaCert%0A-		*out = new(v1.Secret)%0A-		(*in).DeepCopyInto(*out)%0A-	}%0A }%0A %0A // DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new BrokerSpec.%0Adiff --git a/deployments/node/crds/network.fluidos.eu_brokers.yaml b/deployments/node/crds/network.fluidos.eu_brokers.yaml%0Aindex 675efcf..17a3dae 100644%0A--- a/deployments/node/crds/network.fluidos.eu_brokers.yaml%0A+++ b/deployments/node/crds/network.fluidos.eu_brokers.yaml%0A@@ -46,153 +46,9 @@ spec:%0A                 description: Address of the Broker.%0A                 type: string%0A               cacert:%0A-                description: |-%0A-                  Secret holds secret data of a certain type. The total bytes of the values in%0A-                  the Data field must be less than MaxSecretSize bytes.%0A-                properties:%0A-                  apiVersion:%0A-                    description: |-%0A-                      APIVersion defines the versioned schema of this representation of an object.%0A-                      Servers should convert recognized schemas to the latest internal value, and%0A-                      may reject unrecognized values.%0A-                      More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources%0A-                    type: string%0A-                  data:%0A-                    additionalProperties:%0A-                      format: byte%0A-                      type: string%0A-                    description: |-%0A-                      Data contains the secret data. Each key must consist of alphanumeric%0A-                      characters, '-', '_' or '.'. The serialized form of the secret data is a%0A-                      base64 encoded string, representing the arbitrary (possibly non-string)%0A-                      data value here. Described in https://tools.ietf.org/html/rfc4648#section-4%0A-                    type: object%0A-                  immutable:%0A-                    description: |-%0A-                      Immutable, if set to true, ensures that data stored in the Secret cannot%0A-                      be updated (only object metadata can be modified).%0A-                      If not set to true, the field can be modified at any time.%0A-                      Defaulted to nil.%0A-                    type: boolean%0A-                  kind:%0A-                    description: |-%0A-                      Kind is a string value representing the REST resource this object represents.%0A-                      Servers may infer this from the endpoint the client submits requests to.%0A-                      Cannot be updated.%0A-                      In CamelCase.%0A-                      More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds%0A-                    type: string%0A-                  metadata:%0A-                    description: |-%0A-                      Standard object's metadata.%0A-                      More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata%0A-                    properties:%0A-                      annotations:%0A-                        additionalProperties:%0A-                          type: string%0A-                        type: object%0A-                      finalizers:%0A-                        items:%0A-                          type: string%0A-                        type: array%0A-                      labels:%0A-                        additionalProperties:%0A-                          type: string%0A-                        type: object%0A-                      name:

[fluidos-bot]

The go.mod and/or go.sum files appear not to be correctly tidied.

Please, rerun go mod tidy to fix the issues.

[fluidos-bot]

The generated artifacts appear to be out-of-date.

Please, ensure you are using the correct version of the generators (eg. controller-gen) and re-run:

make generate

Here it is an excerpt of the diff:

diff --git a/go.mod b/go.mod%0Aindex 36ae7d7..1cf6cc7 100644%0A--- a/go.mod%0A+++ b/go.mod%0A@@ -1,9 +1,7 @@%0A module github.com/fluidos-project/node //node%0A %0A-%0A go 1.24.0%0A %0A-%0A require (%0A 	github.com/gorilla/mux v1.8.1%0A 	github.com/liqotech/liqo v1.0.0

[andreacv98]

LGTM