The operartor-sdk init command fails for helm chart with bundled dependencies

[sukhil-suresh]

Bug Report

What did you do?

Ran theoperator-sdk init command against a helm chart which has bundled sub-charts and the main Chart.yaml file has the dependencies entry specified with the file:// address resolver.

Command

operator-sdk init --plugins=helm \
  --helm-chart=/repo/helm/k10 \
  --project-name=k10-kasten-operator  \
  --domain=io --group=apik10.kasten \
  --version=v1alpha1 \
  --kind=K10

The /repo/helm/k10/Chart.yaml file

apiVersion: v2
description: Kasten’s K10 Data Management Platform
name: k10
version: v0.1.0-alpha
appVersion: v0.1.0-alpha
home: https://kasten.io/
maintainers:
  - email: contact@kasten.io
    name: kastenIO
icon: https://docs.kasten.io/_static/kasten.png
dependencies:
  - name: grafana
    version: 6.32.9
    repository: file://./charts/grafana
  - name: prometheus
    version: 15.8.5
    repository: file://./charts/prometheus

What did you expect to see?

Expected the operator-sdk init command to work successfully.

What did you see instead? Under which circumstances?

The operator-sdk init command failed.

It looks like the operator-sdk init command copies the bundled sub-charts as .tgz files under the generated helm-charts folder and the internally called operator-sdk create api command fails to pick up the sub-charts since the dependencies repository locations in the Chart.yaml file are no longer resolvable.

Complete logs...

operator-sdk init --project-name=k10-kasten-operator --plugins=helm --domain=io --group=apik10.kasten --version=v1alpha1 --kind=K10 --helm-chart=/repo/helm/k10
Writing kustomize manifests for you to edit...
Creating the API:
$ operator-sdk create api --group apik10.kasten --version v1alpha1 --kind K10 --helm-chart /repo/helm/k10
Writing kustomize manifests for you to edit...

Error: failed to create API: unable to scaffold with "base.helm.sdk.operatorframework.io/v1": failed to fetch chart dependencies: directory /repo/helm-charts/k10/charts/grafana not found
Usage:
  operator-sdk create api [flags]

Examples:
  $ operator-sdk create api \
      --group=apps --version=v1alpha1 \
      --kind=AppService

<cropped-the-examples-string>

Flags:
      --group string                resource Group
      --version string              resource Version
      --kind string                 resource Kind
      --helm-chart string           helm chart
      --helm-chart-repo string      helm chart repository
      --helm-chart-version string   helm chart version (default: latest)
  -h, --help                        help for api

Global Flags:
      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

FATA[0000] failed to create API: unable to scaffold with "base.helm.sdk.operatorframework.io/v1": failed to fetch chart dependencies: directory /repo/helm-charts/k10/charts/grafana not found
Error: failed to initialize project: unable to run post-scaffold tasks of "base.helm.sdk.operatorframework.io/v1": exit status 1
Usage:
  operator-sdk init [flags]

Examples:
  $ operator-sdk init --plugins=base.helm.sdk.operatorframework.io/v1 \
      --domain=example.com \
      --group=apps \
      --version=v1alpha1 \
      --kind=AppService

<cropped-the-examples-string>

Flags:
      --project-version string      project version (default "3")
      --domain string               domain for groups (default "my.domain")
      --project-name string         name of this project
      --component-config            create a versioned ComponentConfig file, may be 'true' or 'false'
      --group string                resource Group
      --version string              resource Version
      --kind string                 resource Kind
      --helm-chart string           helm chart
      --helm-chart-repo string      helm chart repository
      --helm-chart-version string   helm chart version (default: latest)
  -h, --help                        help for init

Global Flags:
      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

FATA[0001] failed to initialize project: unable to run post-scaffold tasks of "base.helm.sdk.operatorframework.io/v1": exit status 1

Environment

Operator type:

/language helm

Kubernetes cluster type:

OpenShift 4.10.17

$ operator-sdk version

operator-sdk version: "v1.24.1", commit: "1a1c56f7d0c7cfcc16e1ff2140caaa6d831b669b", kubernetes version: "1.24.2", go version: "go1.18.7", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

go version go1.19.3 linux/amd64

$ kubectl version

{
  "clientVersion": {
    "major": "1",
    "minor": "24",
    "gitVersion": "v1.24.0",
    "gitCommit": "4ce5a8954017644c5420bae81d72b09b735c21f0",
    "gitTreeState": "clean",
    "buildDate": "2022-05-03T13:46:05Z",
    "goVersion": "go1.18.1",
    "compiler": "gc",
    "platform": "linux/amd64"
  },
  "kustomizeVersion": "v4.5.4",
  "serverVersion": {
    "major": "1",
    "minor": "23",
    "gitVersion": "v1.23.5+3afdacb",
    "gitCommit": "3c28e7a79b58e78b4c1dc1ab7e5f6c6c2d3aedd3",
    "gitTreeState": "clean",
    "buildDate": "2022-05-10T16:30:48Z",
    "goVersion": "go1.17.5",
    "compiler": "gc",
    "platform": "linux/amd64"
  }
}

Possible Solution

Additional context

[varshaprasad96]

Operator-sdk internally uses helm's helpers to load the chart directory with the dependent sub charts (

operator-sdk/pkg/helm/release/manager_factory.go

Lines 75 to 78 in b158b7e

	crChart, err := loader.LoadDir(f.chartDir)
	if err != nil {
	return nil, fmt.Errorf("failed to load chart dir: %w", err)
	}

). Since the error says failed to fetch chart dependencies: directory /repo/helm-charts/k10/charts/grafana not found I'm not sure if this is an issue with the input. Can you try helm template command to check if it works locally (https://helm.sh/docs/helm/helm_template/)

[jberkhahn]

The most common reason this happens is you need to have all the dependencies downloaded locally on disk. That might fix your problem, if it doesn't please let us know.

[sukhil-suresh]

The problem is that the operator-sdk init command starts by copying the bundled sub-charts as .tgz files under the generated helm-charts folder and the subsequent operator-sdk create api command (invoked by the operator-sdk init command) fails to pick up the sub-charts since the dependencies repository locations in the Chart.yaml file are no longer resolvable.

The helm chart I am using has both the sub-charts in their directories. The chart is valid since I can install the product using the command below...

helm install k10 ./helm/k10 -n kasten-io --create-namespace \
 --set image.repository=rich-access-174020 \
 --set image.tag=deploy.PASSED

You should be able to reproduce this issue by running operator-sdk init command on any helm chart which uses the file:// scheme for listing the dependency repository path. An example is listed below...

..
dependencies:
  - name: grafana
    version: 6.32.9
    repository: file://./charts/grafana  # this path will not resolve in the generated `helm-charts` folder since the `operator-sdk init` command replaces the grafana directory as `grafana.tgz`
  - name: prometheus
    version: 15.8.5
    repository: file://./charts/prometheus  # this path will not resolve in the generated `helm-charts` folder since the `operator-sdk init` command replaces the prometheus directory as `prometheus.tgz`

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[homily707]

same probelm， is there any progress

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[efiacor]

Can this issue be reopened? We are facing the same problem.