Add helm chart to release

[jonnylangefeld]

Problem
Currently there is an operator.yaml attached to each release which is generated with bash scripts upon each release. However all namespaced resources in that release are installed in the default namespace which might not be suitable for larger production clusters.

We would like to install knative via a helm chart where the namespace is set to {{ .Release.Namespace }}.

The reason why I think this should be added upstream is because even if you make your own helm chart using the operator yaml from the release via curl -sLo knative/templates/operator.yaml https://github.com/knative/operator/releases/download/knative-v1.1.0/operator.yaml, then you still need to manually replace the namespaces and move the CRDs into a crd directory (otherwise helm can't install a KnativeServing resource in the same release.

Persona:
System Operator

Exit Criteria
Helm chart is attached to the release and operators can run something like

helm repo add knative https://knative.dev
helm install knative knative/knative

Time Estimate (optional):
2 days

[houshengbo]

@jonnylangefeld There is another initiative that kn-plugin-operator is under development, which can resolve the issues regarding all namespaces. You can take a look at: https://github.com/knative-sandbox/kn-plugin-operator
This kn plugin is leveraging all the capability of the knative operator.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[Morriz]

@houshengbo can this be re-opened? I think it is still valid as the suggestion to install yet another cli into our pipeline is unnecessary and adds to shipping bloat.

If 99% of the k8s population is known to use helm charts, and delivering one is very easy (just ask the community to set it up), then why oppose this?

[batazor]

@jonnylangefeld @houshengbo Maybe we should reopen this issue or create a new one? Without a public chart, it is not very easy to update the operator

[Morriz]

Also, if the knative cli is not needed to install an operator (which is usually a very simple chart), then I wouldn't like to be forced to use it. @houshengbo why introduce unnecessary dependencies?

[Morriz]

So strange to see that knative is still not serving the larger audience that uses helm.

[jonnylangefeld]

I agree, a separate cli to install the operator isn’t quite what we’re looking for. Our CD pipeline installs lots of helm charts from public and in-House sources. It would be great if knative could just be another chart in that list.

/reopen

[knative-prow]

@jonnylangefeld: Reopened this issue.

In response to this:

I agree, a separate cli to install the operator isn’t quite what we’re looking for. Our CD pipeline installs lots of helm charts from public and in-House sources. It would be great if knative could just be another chart in that list.

/reopen

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.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[batazor]

upd

[AlyIbrahim]

Adding a helm chart to the operator will simplify the installation through GitOps and using Automation tools like (Terraform, CDK, ArgoCD, etc..)

kn CLI is very good but should not be a dependency for the installation.

There are usually 2 different personas for installation and developing and using Knative, and we should be able to support different toolsets

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[batazor]

upd

[acelinkio]

Knative's focus has been on users who are already using Docker or willing to bring up a VM. I am finished with my local development and want to host only to be thrown into a rabbit hole.

• Docs are rough. https://knative.dev/docs/ keeps pointing you to the doc github, not to the source code for the related serving/eventing/functions projects. Any links to source code for those, take you to main instead of the version.
• Windows/WSL2 users are pushed to using Knative func with remoting. Remoting requires Tekton.
• Installation requires manifests from release pages or using the operator.
• There is no helloworld function to sanity check with. Troubleshooting setup then escalates to needing to debug everything.

I am not opposed to push towards utilizing an operator. The issue is that operators are often not used and as a result not maintained, including Tekton tektoncd/operator#1613 and tektoncd/operator#1493. OperatorLifecycleManager project has an awesome goal of handling operators lifecycle, however everyone I've talked to has avoided OLM because of their terrible experiences.

Hardcoding the namespace is acceptable, but not to default. I get wanting to avoid having to support multiple helm charts for each component by relying upon an operator to manage that. If we could get at least get a helm chart for installing the operator, that would be awesome!