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

v1.0.1 breaks dynamic Chart.yaml names #507

Closed
nerdingas-armaitis opened this issue Jun 10, 2024 · 14 comments
Closed

v1.0.1 breaks dynamic Chart.yaml names #507

nerdingas-armaitis opened this issue Jun 10, 2024 · 14 comments

Comments

@nerdingas-armaitis
Copy link

Hi,

I have an app of apps with bunch of argocd applications and couple of them have dynamic names. This worked perfectly fine on 1.0.0, but is now broken on 1.0.1. Maybe the order of name check vs interpolation has changed?

It still displays name of application correctly in the argocd ui even on 1.0.1.

Application definition:

kind: Application
metadata:
  name: app-<vault:xxx/data/xxx~xxx>-xxx

Error in the logs:

ComparisonError: 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. error generating manifests in cmp: rpc error: code = Unknown desc = error generating manifests: `argocd-lovely-plugin` failed exit status 1: 2024/06/10 12:33:15 exit status 1: Error: validation: chart.metadata.name "app-<vault:xxx/data/xxx~xxx>-xxx" is invalid

Work around:
rollback to 1.0.0

@Joibel
Copy link
Contributor

Joibel commented Jun 10, 2024

Is this an application part of an app of apps? You're running it through lovely-vault? I wonder if lovely-vault is broken - are there any logs from the container other than this?
The changelog is only for dependencies, so I can't see a likely candidate for breaking this.

@nerdingas-armaitis
Copy link
Author

yes - application is part of an app of apps.
yes - app of apps is using lovely-vault for deployment (I think that was the only way to get dynamic names to work)

I have also looked at the changelog and could not see anything incriminating. Maybe its the helm version changes in the dockerfile?

I have tried rolling forward and backwards couple of times and it always behaves the same.

These are the only logs from the lovely-plugin container.

10/06/2024, 13:21:21.650	
time="2024-06-10T12:21:21Z" level=info msg="Generating manifests with no request-level timeout"
	
	
10/06/2024, 13:21:21.650	
time="2024-06-10T12:21:21Z" level=info msg=argocd-lovely-plugin dir=/tmp/_cmp_server/7aa0ba20-e903-4243-99fb-ebfb381f4042/kubernetes/xxx execID=dca77
	
	
10/06/2024, 13:21:23.859	
time="2024-06-10T12:21:23Z" level=error msg="`argocd-lovely-plugin` failed exit status 1: 2024/06/10 12:21:23 exit status 1: Error: validation: chart.metadata.name \"xxx-<vault:xxx>-xxx\" is invalid" execID=dca77
	
	
10/06/2024, 13:21:23.865	
time="2024-06-10T12:21:23Z" level=error msg="finished streaming call with code Unknown" error="error generating manifests: `argocd-lovely-plugin` failed exit status 1: 2024/06/10 12:21:23 exit status 1: Error: validation: chart.metadata.name \"xxx-<vault:xxx>-xxx\" is invalid" grpc.code=Unknown grpc.method=GenerateManifest grpc.service=plugin.ConfigManagementPluginService grpc.start_time="2024-06-10T12:21:21Z" grpc.time_ms=2419.062 span.kind=server system=grpc

@Joibel
Copy link
Contributor

Joibel commented Jun 12, 2024

Seeing as I don't really know what is going on, can you see if 1.0.3 does any better for you?

@nerdingas-armaitis
Copy link
Author

Just tried 1.0.3 - same issue

@Joibel
Copy link
Contributor

Joibel commented Jun 12, 2024

Thanks for trying

@nerdingas-armaitis
Copy link
Author

nerdingas-armaitis commented Jun 12, 2024

I have done some trials with custom built image and it looks like upgrading helm dependency in the dockerfile to 3.14.1+ is what breaks the functionality.

ARG HELM_VERSION=v3.14.1

Helm change log for 3.14.1 just mentions a security fix, looks like they started validating chart names:

helm/helm@v3.14.0...v3.14.1

@Joibel
Copy link
Contributor

Joibel commented Jun 12, 2024

But this is an application, not a Chart.yaml?

@nerdingas-armaitis
Copy link
Author

you are right, it is also in the chart name

Chart.yaml

apiVersion: v2
name: xxx-<vault:xxx~xxx>-xxx
version: 0.0.1

@Joibel
Copy link
Contributor

Joibel commented Jun 13, 2024

So, the app-of-apps is a Chart in itself. Can you elaborate on the directory structure of this application, in particular where the Chart.yaml(s) are?

@nerdingas-armaitis
Copy link
Author

argocd application (/applications/argocd.yaml) which deploys app of apps (/argocd/yaml/app-of-apps.yaml) definition as part of itself
app-of-apps has an xxx-vault:xxx~xxx-xxx application (/applications/yyy.yaml)
xxx-vault:xxx~xxx-xxx application defines a chart (/yyy/Chart.yaml) named xxx-vault:xxx~xxx-xxx

is that a non recommended/supported way?

@Joibel
Copy link
Contributor

Joibel commented Jun 13, 2024

I only care about the application structure of the one application that is causing issues.

Is that a the last of these, or the app of apps?

The structure of the failing application has a Chart.yaml in the root directory with a vault substituted name in it?

@nerdingas-armaitis
Copy link
Author

correct, it is the yyy application that is causing the issue (not the app of apps)
yes, the failing application is just a Chart.yaml (with a vault substituted name) that has a dependency defined (the actual chart) + values.yaml in a directory

Chart.yaml

apiVersion: v2
name: xxx-<vault:xxx~xxx>-xxx
version: 0.0.1

dependencies:
  - name: zzz
    version: 1.2.3
    repository: zzz

@Joibel
Copy link
Contributor

Joibel commented Jun 13, 2024

So, this worked before Helmet 3.14.1 because the helm template expansion could work because it just didn't care about the name at that stage. It now cares about the name.

Template expansion happens before the vault substitution with lovely-vault out of the box. It "worked" because all the places the helm name were used inside your templates got substituted after expansion, and everything was doozy.

So, you have a couple of options:

  • Pass the "name" in as some other variable in values.yaml, so helm doesn't complain. A pain to implement making your charts a bit non-standard.
  • Use LOVELY_PREPROCESSORS to do the name substitution before helm gets invoked. If you have stronger bash skills you might be able to sanely do this in place, but in the interests of getting on with other stuff I'm going to suggest you have a Chart.tpl and do LOVELY_PREPROCESSORS: "argocd-vault-replacer < Chart.tpl > Chart.yaml". This suggestion comes to you completely untested. You're most welcome.

@Joibel Joibel changed the title v1.0.1 breaks dynamic application names v1.0.1 breaks dynamic Chart.yaml names Jun 13, 2024
@nerdingas-armaitis
Copy link
Author

Thanks, that seems to work even in 1.0.3.

I had to move the definitions from the root folder to ./chart folder for the pre-processor to work, but otherwise all good.

definition in the app if anyone ever encounters this:

    plugin:
      name: lovely-vault
      env:
        - name: LOVELY_PREPROCESSORS_YAML
          value: |-
            chart:
            - "argocd-vault-replacer < Chart.tpl > Chart.yaml"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants