feat: update to Talos 1.0

Update compatibility matrix, etc.

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

Dockerfile

@@ -42,8 +42,8 @@ ARG CGO_ENABLED
 ENV CGO_ENABLED ${CGO_ENABLED}
 ENV GOCACHE /.cache/go-build
 ENV GOMODCACHE /.cache/mod
-RUN --mount=type=cache,target=/.cache go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.6.2
-RUN --mount=type=cache,target=/.cache go install k8s.io/code-generator/cmd/conversion-gen@v0.21.3
+RUN --mount=type=cache,target=/.cache go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.8.0
+RUN --mount=type=cache,target=/.cache go install k8s.io/code-generator/cmd/conversion-gen@v0.23.1
 RUN --mount=type=cache,target=/.cache go install mvdan.cc/gofumpt/gofumports@v0.1.1
 RUN curl -sfL https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | bash -s -- -b /toolchain/bin v1.43.0
 WORKDIR /src

Makefile

@@ -9,7 +9,7 @@ MODULE := $(shell head -1 go.mod | cut -d' ' -f2)
 
 ARTIFACTS := _out
 TEST_PKGS ?= ./...
-TALOS_RELEASE ?= v0.14.1
+TALOS_RELEASE ?= v1.0.0
 PREVIOUS_TALOS_RELEASE ?= v0.13.4
 DEFAULT_K8S_VERSION ?= v1.22.3
 

README.md

@@ -14,8 +14,11 @@ This provider's versions are compatible with the following versions of Cluster A
 
 |                              | v1alpha3 (v0.3) | v1alpha4 (v0.4) | v1beta1 (v1.0) |
 | ---------------------------- | --------------- | --------------- | -------------- |
-| Sidero Provider v1alpha3 (v0.3) | ✓               |                 |                |
-| Sidero Provider v1alpha3 (v0.4) |                 | ✓               |                |
+|                        | v1alpha3 (v0.3) | v1alpha4 (v0.4) | v1beta1 (v1.x) |
+| ---------------------- | --------------- | --------------- | -------------- |
+| Sidero Provider (v0.3) | ✓               |                 |                |
+| Sidero Provider (v0.4) |                 | ✓               |                |
+| Sidero Provider (v0.5) |                 |                 | ✓              |
 
 This provider's versions are able to install and manage the following versions of Kubernetes:
 
@@ -26,10 +29,13 @@ This provider's versions are able to install and manage the following versions o
 
 This provider's versions are compatible with the following versions of Talos:
 
-|                              | v0.11 | v 0.12 | v0.13 |
-| ---------------------------- | ----- | ------ | ----- |
-| Sidero Provider v1alpha3 (v0.3) | ✓     | ✓      |       |
-| Sidero Provider v1alpha3 (v0.4) | ✓     | ✓      | ✓     |
+|                        | v0.11 | v0.12  | v0.13 | v0.14 | v1.0  |
+| ---------------------- | ----- | ------ | ----- | ----- | ----- |
+| Sidero Provider (v0.3) | ✓     | ✓      |       |       |       |
+| Sidero Provider (v0.4) | ✓     | ✓      | ✓     | ✓     |       |
+| Sidero Provider (v0.5) |       | ✓ (+)  | ✓ (+) | ✓     | ✓     |
+
+> (+): Some Sidero 0.5 features (SideroLink) are only available with Talos v0.14+.
 
 ## Support
 

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

@@ -1,10 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.6.2
+    controller-gen.kubebuilder.io/version: v0.8.0
   creationTimestamp: null
   name: metalclusters.infrastructure.cluster.x-k8s.io
 spec:

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

@@ -1,10 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.6.2
+    controller-gen.kubebuilder.io/version: v0.8.0
   creationTimestamp: null
   name: metalmachines.infrastructure.cluster.x-k8s.io
 spec:
@@ -46,26 +45,25 @@ spec:
                 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
+                  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
+                  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
+                  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
                   .'
                 properties:
                   apiVersion:
@@ -197,26 +195,25 @@ spec:
                 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
+                  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
+                  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
+                  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
                   .'
                 properties:
                   apiVersion:
@@ -256,26 +253,25 @@ spec:
                 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
+                  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
+                  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
+                  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
                   .'
                 properties:
                   apiVersion: