chore: bump dependencies in go.mod

This also bumps cluster-api version to the latest 0.3 release.

Closes #476 #484 #486 #487 #490 #491 #492 #493

Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>

Dockerfile

@@ -87,7 +87,7 @@ COPY --from=generate-build /src/app/caps-controller-manager/api ./app/caps-contr
 COPY --from=generate-build /src/app/sidero-controller-manager/api ./app/sidero-controller-manager/api
 COPY --from=generate-build /src/app/sidero-controller-manager/internal/api ./app/sidero-controller-manager/internal/api
 
-FROM --platform=${BUILDPLATFORM} alpine:3.13 AS release-build
+FROM --platform=${BUILDPLATFORM} alpine:3.14 AS release-build
 ADD https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv4.1.0/kustomize_v4.1.0_linux_amd64.tar.gz .
 RUN  tar -xf kustomize_v4.1.0_linux_amd64.tar.gz -C /usr/local/bin && rm kustomize_v4.1.0_linux_amd64.tar.gz
 COPY ./config ./config

Makefile

@@ -11,8 +11,8 @@ ARTIFACTS := _out
 TEST_PKGS ?= ./...
 TALOS_RELEASE ?= v0.11.0-beta.2
 
-TOOLS ?= ghcr.io/talos-systems/tools:v0.5.0
-PKGS ?= v0.5.0-8-gb0d9cd2
+TOOLS ?= ghcr.io/talos-systems/tools:v0.6.0
+PKGS ?= v0.6.0
 
 SFYRA_CLUSTERCTL_CONFIG ?= $(HOME)/.cluster-api/clusterctl.sfyra.yaml
 

app/caps-controller-manager/config/crd/bases/infrastructure.cluster.x-k8s.io_metalmachines.yaml

@@ -38,7 +38,7 @@ spec:
                 description: ProviderID is the unique identifier as specified by the cloud provider.
                 type: string
               serverRef:
-                description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                description: ObjectReference contains enough information to let you inspect or modify the referred object.
                 properties:
                   apiVersion:
                     description: API version of the referent.
@@ -122,7 +122,7 @@ spec:
                 description: ProviderID is the unique identifier as specified by the cloud provider.
                 type: string
               serverClassRef:
-                description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                description: ObjectReference contains enough information to let you inspect or modify the referred object.
                 properties:
                   apiVersion:
                     description: API version of the referent.
@@ -147,7 +147,7 @@ spec:
                     type: string
                 type: object
               serverRef:
-                description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                description: ObjectReference contains enough information to let you inspect or modify the referred object.
                 properties:
                   apiVersion:
                     description: API version of the referent.

app/caps-controller-manager/config/crd/bases/infrastructure.cluster.x-k8s.io_metalmachinetemplates.yaml

@@ -43,7 +43,7 @@ spec:
                         description: ProviderID is the unique identifier as specified by the cloud provider.
                         type: string
                       serverRef:
-                        description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                        description: ObjectReference contains enough information to let you inspect or modify the referred object.
                         properties:
                           apiVersion:
                             description: API version of the referent.
@@ -105,7 +105,7 @@ spec:
                         description: ProviderID is the unique identifier as specified by the cloud provider.
                         type: string
                       serverClassRef:
-                        description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                        description: ObjectReference contains enough information to let you inspect or modify the referred object.
                         properties:
                           apiVersion:
                             description: API version of the referent.
@@ -130,7 +130,7 @@ spec:
                             type: string
                         type: object
                       serverRef:
-                        description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                        description: ObjectReference contains enough information to let you inspect or modify the referred object.
                         properties:
                           apiVersion:
                             description: API version of the referent.

app/caps-controller-manager/config/crd/bases/infrastructure.cluster.x-k8s.io_serverbindings.yaml

@@ -58,7 +58,7 @@ spec:
             description: ServerBindingSpec defines the spec of the ServerBinding object.
             properties:
               metalMachineRef:
-                description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                description: ObjectReference contains enough information to let you inspect or modify the referred object.
                 properties:
                   apiVersion:
                     description: API version of the referent.
@@ -83,7 +83,7 @@ spec:
                     type: string
                 type: object
               serverClassRef:
-                description: 'ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.  1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.  2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular     restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".     Those cannot be well described when embedded.  3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.  4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity     during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple     and the version of the actual struct is irrelevant.  5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type     will affect numerous schemas.  Don''t make new APIs embed an underspecified API type they do not control. Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .'
+                description: ObjectReference contains enough information to let you inspect or modify the referred object.
                 properties:
                   apiVersion:
                     description: API version of the referent.

app/caps-controller-manager/controllers/metalmachine_controller.go

@@ -189,7 +189,7 @@ func (r *MetalMachineReconciler) reconcileDelete(ctx context.Context, metalMachi
 }
 
 func (r *MetalMachineReconciler) SetupWithManager(mgr ctrl.Manager, options controller.Options) error {
-	if err := mgr.GetFieldIndexer().IndexField(context.Background(), &infrav1.ServerBinding{}, infrav1.ServerBindingMetalMachineRefField, func(rawObj runtime.Object) []string {
+	if err := mgr.GetFieldIndexer().IndexField(&infrav1.ServerBinding{}, infrav1.ServerBindingMetalMachineRefField, func(rawObj runtime.Object) []string {
 		serverBinding := rawObj.(*infrav1.ServerBinding)
 
 		return []string{serverBinding.Spec.MetalMachineRef.Name}
@@ -306,7 +306,6 @@ func (r *MetalMachineReconciler) patchProviderID(ctx context.Context, cluster *c
 	r.Log.Info("Searching for node", "label", label)
 
 	nodes, err := clientset.CoreV1().Nodes().List(
-		ctx,
 		metav1.ListOptions{
 			LabelSelector: label,
 		},
@@ -336,7 +335,7 @@ func (r *MetalMachineReconciler) patchProviderID(ctx context.Context, cluster *c
 
 		node.Spec.ProviderID = providerID
 
-		_, err = clientset.CoreV1().Nodes().Update(ctx, &node, metav1.UpdateOptions{})
+		_, err = clientset.CoreV1().Nodes().Update(&node)
 		if err != nil {
 			return err
 		}

app/caps-controller-manager/controllers/serverbinding_controller.go

@@ -95,7 +95,7 @@ func (r *ServerBindingReconciler) Reconcile(req ctrl.Request) (_ ctrl.Result, er
 }
 
 func (r *ServerBindingReconciler) SetupWithManager(mgr ctrl.Manager, options controller.Options) error {
-	if err := mgr.GetFieldIndexer().IndexField(context.Background(), &infrav1.MetalMachine{}, infrav1.MetalMachineServerRefField, func(rawObj runtime.Object) []string {
+	if err := mgr.GetFieldIndexer().IndexField(&infrav1.MetalMachine{}, infrav1.MetalMachineServerRefField, func(rawObj runtime.Object) []string {
 		metalMachine := rawObj.(*infrav1.MetalMachine)
 
 		if metalMachine.Spec.ServerRef == nil {