Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update of third party addon provider not working #530

Open
guettli opened this issue May 14, 2024 · 1 comment
Open

Update of third party addon provider not working #530

guettli opened this issue May 14, 2024 · 1 comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@guettli
Copy link
Contributor

guettli commented May 14, 2024

What steps did you take and what happened:

We developed an addon provider which is not in the list of known addon providers.

Installing it via the cluster-api-operator works fine.

But during the upgrade we see that Condition, and the controller continuously reconciles:

ProviderUpgraded=False ComponentsUpgradeError "failed to get configuration for the AddonProvider with name foo. Please check the provider name and/or add configuration for new providers using the .clusterctl config file"

We found no way to provide a .clusterctl config, and I think it is not needed.

We provide a configMap:

apiVersion: v1
binaryData:
  components: ...
data:
  metadata: |-
    # maps release series of major.minor to cluster-api contract version
    # the contract version may change between minor or major versions, but *not*
    # between patch versions.
    #
    # update this file only when a new major or minor version is released
    apiVersion: clusterctl.cluster.x-k8s.io/v1alpha3
    releaseSeries:
      - major: 1
        minor: 1
        contract: v1beta1
      - major: 1
        minor: 2
        contract: v1beta1
kind: ConfigMap
metadata:
  annotations:
    provider.cluster.x-k8s.io/compressed: "true"
  labels:
    provider-components: foo
    provider.cluster.x-k8s.io/name: foo
    provider.cluster.x-k8s.io/type: addon
    provider.cluster.x-k8s.io/version: v1.2.1
  name: foo-v1.2.1
  namespace: mgt-system

We found a dirty work-around:

We forked cluster-api-operator, then we did go mod vendor to get the sources of vendor/sigs.k8s.io/cluster-api/cmd/clusterctl/client/config/providers_client.go.

Then we added our provider foo below the existing provider for helm:

providers_client.go#L403

This fixed the issue for us, and we could upgrade our custom addon provider.

What did you expect to happen:

Since the configMap is given, I think the cluster-api-operator should be able to upgrade the third party addon provider, even if the provider is not listed in the file providers_client.go.

Anything else you would like to add:

The cluster-api-operator worked fine for us, and this is our first issue.

Environment:

  • Cluster-api-operator version: v0.10.1
  • Cluster-api version: 1.7.1.
kubectl version                                                                                                                                                                   

Client Version: v1.29.3
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.2

We tried to create a PR to fix that, but we failed.

This following method sometimes found the provider foo and sometimes it did not find the provider:

func (p *providersClient) Get(name string, providerType clusterctlv1.ProviderType) (Provider, error) {

/kind bug

/area/upgrades

@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 14, 2024
@alexander-demicev
Copy link
Contributor

/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

3 participants