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

no matches for kind "ConfigManagementPlugin" in ArgoCD 2.8.0 #15152

Closed
ledroide opened this issue Aug 22, 2023 · 11 comments · Fixed by #15405
Closed

no matches for kind "ConfigManagementPlugin" in ArgoCD 2.8.0 #15152

ledroide opened this issue Aug 22, 2023 · 11 comments · Fixed by #15405
Assignees
Labels
bug Something isn't working

Comments

@ledroide
Copy link

Installation method : manifest from https://raw.githubusercontent.com/argoproj/argo-cd/v2.8.0/manifests/install.yaml
Context : "Support dropped for argocd-cm plugins" - in upgrade notes for ArgoCD 2.7 to 2.8
Doc/guide followed : Migrating from argocd-cm plugins

I have converted this configMapGenerator file for configMap/argocd-cm :

- name: kustomized-helm
  init:
    command: ["/bin/sh", "-c"]
    args: ["helm dependency build"]
  generate:
    command: [sh, -c]
    args: ["helm template --release-name release-name . > all.yaml && kustomize build"]

... to this argoproj resource :

apiVersion: argoproj.io/v1alpha1
kind: ConfigManagementPlugin
metadata:
  name: kustomized-helm
spec:
  init:
    command: ["/bin/sh", "-c"]
    args: ["helm dependency build"]
  generate:
    command: [sh, -c]
    args: ["helm template --release-name release-name . > all.yaml && kustomize build"]

But when applying manifests :

error: resource mapping not found for name: "kustomized-helm" namespace: "argocd" from "./tools/argocd/env/poc": no matches for kind "ConfigManagementPlugin" in version "argoproj.io/v1alpha1"
ensure CRDs are installed first

So I have commented this resource in order to make sure that ArgoCD 2.8.0 is fully installed, including CRDs from the manifest. Then I retried. Same error.

When checking argoproj CRDs, there is no configmanagementplugin.argoproj.io resource :

$ kubectl api-resources --api-group=argoproj.io
NAME              SHORTNAMES         APIVERSION             NAMESPACED   KIND
applications      app,apps           argoproj.io/v1alpha1   true         Application
applicationsets   appset,appsets     argoproj.io/v1alpha1   true         ApplicationSet
appprojects       appproj,appprojs   argoproj.io/v1alpha1   true         AppProject

It is because there is no configmanagementplugin.argoproj.io CRD in manifests/install.yaml - but only applications.argoproj.io, applicationsets.argoproj.io, and appprojects.argoproj.io :

$ curl -s https://raw.githubusercontent.com/argoproj/argo-cd/v2.8.0/manifests/install.yaml | grep -i customresourcedefinition -A5 
kind: CustomResourceDefinition
metadata:
  labels:
    app.kubernetes.io/name: applications.argoproj.io
    app.kubernetes.io/part-of: argocd
  name: applications.argoproj.io
--
kind: CustomResourceDefinition
metadata:
  labels:
    app.kubernetes.io/name: applicationsets.argoproj.io
    app.kubernetes.io/part-of: argocd
  name: applicationsets.argoproj.io
--
kind: CustomResourceDefinition
metadata:
  labels:
    app.kubernetes.io/name: appprojects.argoproj.io
    app.kubernetes.io/part-of: argocd
  name: appprojects.argoproj.io

I did not find the configmanagementplugin.argoproj.io CRD in this repository - I have searched in both branches v2.8.0 and master.
Where is it ?

@crenshaw-dev
Copy link
Collaborator

ConfigManagementPlugin is not an actual CRD. It's a config file that's formatted to look like a CRD. You're meant to embed it in a ConfigMap and mount it into your plugin's sidecar.

I want to remove the CRD-like fields from that file, because it is confusing: #14440

@ledroide
Copy link
Author

Thanks @crenshaw-dev for your help.
I have now this ConfigMap/argocd-cm, that is of course a regular ConfigMap this is applied without error :

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  configManagementPlugins: |
    apiVersion: argoproj.io/v1alpha1
    kind: ConfigManagementPlugin
    metadata:
      name: kustomized-helm
    spec:
      init:
        command: ["/bin/sh", "-c"]
        args: ["helm dependency build"]
      generate:
        command: [sh, -c]
        args: ["helm template --release-name release-name . > all.yaml && kustomize build"]
  kustomize.buildOptions: --enable-helm
  resource.customizations: |
    networking.k8s.io/Ingress:
        health.lua: |
          hs = {}
          hs.status = "Healthy"
          return hs

However I could not find in ArgoCD documentation how to check that the ConfigManagementPlugin is correctly set in the application controller.

How can I check the list of ConfigManagementPlugins ?

@gajus
Copy link

gajus commented Aug 23, 2023

^same question

@prein
Copy link

prein commented Aug 23, 2023

Do I read it right then that the migration guide is misleading and the configManagementPlugins entries stay where they were?

@ledroide
Copy link
Author

@prein : From what I understood from documentation, this :

data: 
  configManagementPlugins: |
    - name: kustomized-helm
      init:
[...]

...should be converted into this :

data: 
  configManagementPlugins: |
    apiVersion: argoproj.io/v1alpha1
    kind: ConfigManagementPlugin
    metadata:
      name: kustomized-helm
    spec:
      init:
[...]

But I could not find a way to check this configuration is correct and taken in account by argocd application controller.

@crenshaw-dev
Copy link
Collaborator

The configManagementPlugins field in the argocd-cm configmap is no longer used, as of 2.8. You're free to use that field, but it's not required.

Basically, the plugin config has to be place in some ConfigMap in the argocd namespace. And then that config must be mounted to plugin.yaml at the appropriate directory in the plugin sidecar. You could mount the plugin.yaml from any ConfigMap. You could even hard-code it into the sidecar image. The end result must be that the plugin.yaml is where the sidecar server expects it to be.

@crenshaw-dev
Copy link
Collaborator

Ah yes. This sentence in the migration guide is doing a lot of work:

After installing the plugin as a sidecar according to the directions above, test it out on a few Applications before migrating all of them to the sidecar plugin.

The migration guide is sending you back up to the top of the page to install the plugin as if you were setting up a completely new plugin. The intention was to avoid duplicating instructions.

I think we need a nice big "THIS IS IMPORTANT" notification before that sentence so that folks don't skim it and miss critical steps.

@ledroide
Copy link
Author

You're free to use that field, but it's not required.

@crenshaw-dev : That means my configuration should work the way I have changed it (see above) ?
How can I check that the plugin is now managed by the application controller ?

@crenshaw-dev
Copy link
Collaborator

That means my configuration should work the way I have changed it (see above) ?

Not quite. Placing the plugin config under that field just means it's available for a sidecar plugin to mount, not that it's actually being mounted. You'll need to follow the instructions to set up the sidecar and mount the plugin config.

How can I check that the plugin is now managed by the application controller ?

Check the logs on the argocd-repo-server sidecar. That'll at least confirm that the plugin is ready to accept work.

@prein
Copy link

prein commented Aug 23, 2023

Thanks, I start to see it and I'm almost there. I am now getting
Failed to load target state: failed to generate manifest for source 1 of 1: rpc error: code = Unknown desc = Manifest generation error (cached): plugin sidecar failed. couldn't find cmp-server plugin with name foo supporting the given repository
Looks like it has to do with version per docs If you do mention the name make sure it is either <metadata.name>-<spec.version> if version is mentioned in the ConfigManagementPlugin spec or else just <metadata.name> and per this comment. I still can't see what I'm missing having tried with and without version specified.

Is discovery pattern required? How do I make it match all

@crenshaw-dev
Copy link
Collaborator

The discovery config is not required. You can specify the plugin just by name (or name-version, if your plugin config includes a version).

You could also just set your discovery config to command: [echo, hi] to make it match all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants