Helm support on odo

[gorkem]

/kind feature

Goal

Developers should be able to use services such as databases, caches, messaging that are installed as Helm charts to the cluster to link with their applications.

Non-goals

Ability to install helm charts using odo is not a primary goal with this enhancement. Creating helm charts for the application developed is NOT a goal.

Use cases

In order of priority

Link a service installed using a helm chart

odo link command should be able to link a service installed using a helm chart.

List services installed using helm

odo service command should be able to list the helm based installed services.

Restore development state from devfile

odo push should be able to restore the development environment including installation of the required helm components.

Dependencies

Need some additional updates from the Service Binding Operator, which are scheduled for GA

Discussion

This enhancement purposely does not include the installation of helm charts via odo. Helm has a very comprehensive CLI and tooling that is familiar for developers. odo should not try to replace those functions provided by the helm CLI but instead complement them on a multi-container, cloud native application development scenario.

JIRA Epic Tracking

ODO-50

[serenamarie125]

Pulling into 2.1 milestone. This work cannot be started until the refactor work is complete. Will check back at end of January to re-evaluate status and 2.1 goal.

[girishramnani]

an open question to the team and maybe even @Gorkem? There are operators that internally use helm or like operators can be driven using helm - so wouldn’t that be enough in terms of providing helm support? issue - https://github.com/openshift/odo/issues/4236

We are also in discussion about allowing an easy way to install operators ( i.e. install using admin rights ) in odo then wouldn’t someone just use a cockroach db helm based operator - install it and use it ? and our current linking feature to that operator would work upfront?

[kadel]

I would say that this won't be enough. This operator uses helm internally, but it is still an operator on the outside.

The point of adding Helm support to odo is to benefit from the Helm ecosystem.

We want users to be able to do just helm install mysql than odo link mysql and have everything ready for the application to connect to the database.

[girishramnani]

We want users to be able to do just helm install mysql than odo link mysql and have everything ready for the application to connect to the database.

but this a very specific chart that would only have one service which we can detect and link to - that will not be the case always.

[girishramnani]

I would also like to ask how hard is it to convert a mysql chart to run as an operator using the "helm backed operator strategy of operator sdk"?

[kadel]

but this a very specific chart that would only have one service which we can detect and link to - that will not be the case always.

The same problem applies to the operator backed services. There is nothing that would guarantee that resources created by an operator include Service.

I would also like to ask how hard is it to convert a mysql chart to run as an operator using the "helm backed operator strategy of operator sdk"?

What problem would this solve?

[sbose78]

We want users to be able to do just helm install mysql than odo link mysql and have everything ready for the application to connect to the database.

+1

[gorkem]

I agree with @kadel. The goal is to be able to support Helm. Helm operator instructions is a mile long, we can not expect developers to go through it because they wanted to deploy a DB during development.

[kadel]

Implementation of this should not be that complicated.

The first part is extending odo service list list of installed charts.

We can check the Helm source code to check how helm list does that. Or if we are saying that we need Service in order to create a link we can use labels and annotations that Helm is labeling all objects. For example to list Services that belong to Helm chart you could do something like this

▶ kubectl get svc -l app.kubernetes.io/managed-by=Helm -o jsonpath="Service.name | Helm.release-name{'\n'}{range .items[*]}{.metadata.name}  |  {.metadata.annotations.meta\.helm\.sh\/release-name}{'\n'}{end}"

Service.name | Helm.release-name
mongodb  |  mongodb
my-mysql  |  my-mysql
my-mysql-slave  |  my-mysql

Now we know both the Helm release name and Service.

So now odo link my-mysql can easily generate ServiceBinding or in this case two ServiceBindigs as there are two Services assuming that SBO can create two SBs for one Deployment (@sbose78 ?). If not users will have to pass extra parameters to odo link narrowing it down to just one Service.

[kadel]

Started putting together how this should work and how it can be implemented.

https://github.com/openshift/odo/pull/4413

It looks like there might be some blockers. Need to investigate further.

[kadel]

I've looked into doing linking using Service Binding Operator. The outcome of my research is that it is not possible to construct ServiceBinding in a way that would allow linking to Helm Chart.

On problem is that there is no standard way how Helm Charts are exposing information about how to connect to the provided service. One way to approach this could be assuming that any Service and Secret created by Helm Chart is providing connect information.

The other problem is Service Binding Operator. Currently, it is not possible to directly specify Secret or Service as a binding service in ServiceBinding https://github.com/redhat-developer/service-binding-operator/issues/872 We would have to modify resources created by Helm and add annotations and ownerReferences to make SBO work with Helm Charts.

We either need to wait for SBO to implement the necessary functionality or try to implement linking between the odo component and Helm charts ourselves inside odo.

[wtrocki]

I would like to jump on the issue with slight different variation.

Currently, ODO recognizes services as Operator Backend Backends which are basically CR + deployments. Service Binding Operator abstracts from that model and will allow to bind any CR - even the one that doesn't have particular deployment - This is great feature - it just needs CR.

When considering adding helm it will be good to see if ODO can provide a flexible way to define what is service by using labels etc.

For example

app.kubernetes.io/component="external-service"
app.kubernetes.io/managed-by="some-external-service-operator | HELM | ANYTHING FANCY IN FUTURE"

This will not only support helm but also "Other" services.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 90 days. Stale issues will be closed after an additional 30 days of inactivity.