Integrate Bitnami with kubeapps

[clintkitson]

The roadmap describes this feature as Bitnami integration via kubeapps (Oct-Dec).

Proposal

Make Bitnami catalog of apps available so TCE users can easily discover, inspect, and deploy Bitnami apps. This requires translating the Bitnami catalog into a Carvel package repository bundle and making it available.

Background

The Bitnami catalog has 130+ curated applications the community members can benefit from if consumed through TCE, see here.

There was a prototype performed by a community member (@vrabbi) here which demonstrates it is possible to apply Carvel packaging to Bitnami catalog apps also see conversation here. The prototype accomplishes this using native tooling to generate manifests and install existing Helm charts as package install objects.

Questions

• What should the experience be like for someone making use of Bitnami packages in TCE?
• If TCE is directly describing how to make use of this bundle or other bundles in the future, is it necessary to qualify the functionality of packages at this or additional locations?
• Is there functionality that is missing key to TCE when a translation occurs and it is not packaged natively with Carvel?
• What if a user installs packages that might be redundant between the two?
• How should TCE redirect community issues relating to packages that are deployed through external packager repository bundles?

High level implementation path

TCE already makes use of package repository bundles. The questions above will provide answers for an implementation path where documentation and/or tool updates take place to reference additional possibly community-maintained curated package repository bundles.

[github-actions]

Hey @clintkitson! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Tanzu Community Edition.

[joshrosso]

A distinction I'd like to understand:

Is the desire to (a or b):

a. Get Bitanmi's existing app catalog into a kapp-controller consumable format
b. Package kubeapps and make it deployable into TCE cluster

It's important to note that kubeapps is its own deployment, that runs in the cluster and exposes a dashboard/catalog. In theory, kubeapps could be packaged using Carvel today and users could deploy it into their TCE clusters. Based on the kubeapps architecture this should work fine, however the dashboard's communication with Kubeops means that users installing packages, under the hood, would be communicating with helm. Technically fine, but would create an interesting UX where packages installed by kubeapps would not be reflected using tanzu package < command >.

If our desire is to solely provide carvel packages reflecting the existing bitnami Catalog, we can focus on that, but it is a separate concern from running kubeapps.

cc @qnetter

[vrabbi]

I think both having kubeapps as a package as well as having the bitnami charts as packages are both very valuable additions.
There is also ongoing work in kubeapps to add support for deploying carvel packages and not just helm charts. When that is done in kubeapps the deployment of kubeapps i believe will be even more interesting amd usefull in TCE as tanzu cli can be the CLI approach and kubeapps the UI approach for achieving the same end goal of installing a package.
Regarding the questions asked above:
What should the experience be like for someone making use of Bitnami packages in TCE?

• i think the ideal is to have the same experience when installing a bitnami chart as when installing a core TCE package.

If TCE is directly describing how to make use of this bundle or other bundles in the future, is it necessary to qualify the functionality of packages at this or additional locations?

• I think anything released by TCE needs to be tested and functionality must be qualified, jiwever thats where a community model for packages could be beneficial. I view it like krew hosts an index of accepted projects into the krew plugin registry but take no ownership over the packages. When installijg a plugin via krew you get even a printed message that mentioms this explicitly. I think a similar approach with community packages would make sense.

Is there functionality that is missing key to TCE when a translation occurs and it is not packaged natively with Carvel?

• from my experience nothing is lost when using helm in packages rather then ytt. The only bad part is using helm and not ytt but from a kapp controller and packaging side you can still get the same abilities. Also you can create packages with helm and ytt together if for example custom overlays become natively supported in TCE packages.

What if a user installs packages that might be redundant between the two?

• this is i believe not an issue. TCE offers different packages and it is up to the user what to install, how and where. Its similar to having snap and apt on ubuntu. You can shoot yourself in the foot by installing the same tool via both but that risk i think isnt a critical one, as long as the packages are in seperate package repos.

How should TCE redirect community issues relating to packages that are deployed through external packager repository bundles?

• again here i think an approach like krew which points people to the source repo where the package repo code is located makes the most sense.

In general i think this comes to the need for a TCE package repo index for community packages. This allows for discovery of such tooling but doesnt put the burden on TCE developers to maintain all of the packages.
Standards should be set by TCE on what minimal reqs must be adhered by in order to have a community repo indexed in TCE and then it could be a simple git issue/pr to add a package repo to the index which could be brought of for concensus at a community meeting and then approved or rejected

[joshrosso]

From our office hours today, I'm wondering if the following is the right plan:

1. "Conversion" of bitnami catalog to Carvel packages.
   • This could just be wrapping the Helm charts in the packaging CRD/APIs.
2. Include an updated version of kubeapps which is capable of talking tokapp-controller/ the carvel packaging APIs

@cppforlife is this a convo that is actively going on for between Bitnami and Carvel?

[joshrosso]

To move forward with this ask, we need this issue to be updated with a proposal, which describes what we are trying to do.

For now, we're moving this to the icebox.

[garrying]

Keen to see Kubeapps included as a package! A few open-ended thoughts from looking at v2.4.2 with kapp-controller plugin deployed on TCE (Unmanaged). Note, the plugin is in Developer Preview:

• The Catalog is showing Carvel packages amongst Helm charts. For example cert-manager:
  • Distinguishing the packages vs charts is one facet to it, but I also wonder how user's will decided and if there's a way to provide some guidance. snap vs apt is an interesting analogy to view this from, though it makes me reflect on challenges in providing clear guidance/support for novice users
• In addition to Repository as a filter, it could be interesting to have a more noticeable demarcation between Tanzu/TCE packages and bitnami charts
• From a package discoverability point-of-view, I think the Catalog UI is a sensible approach to support user's in finding and deploying what they need. There's probably more to explore in this space.

[vrabbi]

The next version of kubeapps which should be very soon is adding a lot of functionality to carvel package management and will make them really work well from initial testing. I think that having a package for kubeapps would be great and as it has moved to a plugin model even for the core helm chart support, maybe from a UX perspective the default value could be enable carvel and disable helm but allow a user to swap those flags? This would give a streamlined UI for the packages and not confuse helm charts with packages however still allow the user to enable the helm or flux plugins if they desire.
The main benefit we will be gaining beyond stability speed and a lot of nice things in the next release of kubeapps is that packages will now show there default values in the deployment form and allow editing the default yaml (currently its an empty text area to paste a yaml in). Having this is allowing for a really good UX for deploying a package and not needing to run 3 commands (list - to get the name, list - to get version, get --values-schema - to get the values) and then build a yaml manually to build a values file for installing a package

[joshrosso]

@clintkitson any idea who should own this proposal and process?

[joshrosso]

Just checked and there's been internal communication around a new proposal to be opened around kubeapps inclusion.