suggestions from Renjie

[jichenjc]

@jiere you mentioned some questions in helm chart in last week meeting
@jiangphcn can you help check this ? Thanks

[jiere]

Thanks @jichenjc for reminding, really appreciated :-)
Generally speaking, some of our customers like use Helm Chart to deploy their cloud native applications, so they have been trying Helm also on Kepler.
They have some confusion when read and try our community document guide here, we may re-visit document and do proper enhancement or fix if necessary.

Some of the issues can be covered by my previously raised issue #34.
Some are new since recently @sthaha did quite a lot great jobs on kepler-operator side.
So we'd better align with the operator jobs to show overall excellent and consistent user experience on Kepler deployment, avoid redundant or inconsistent behavior between helm-chart side and operator side.

@sthaha once showed his idea to use Helm Chart deploy kepler-operator and then use the kepler-operator to deal with all of those Kepler deployment stuffs, this is OPEN to me and may need community discussion.

Another confusion which we get feedbacks from customers on our document is about the local cluster deployment and Openshift deployment description, they may neither use Openshift nor Kind, but just vanilla multiple-nodes Kubernetes clusters.
We should also take consideration for such scenario when we do enhancement both on code and document.

[jiangphcn]

thanks @jichenjc and @jiere for your information and follow-up. Based on #53 (comment), my current understanding is

1. need to verify community document guide here. So far, it there known issue with this guide?
2. "use Helm Chart deploy kepler-operator and then use the kepler-operator to deal with all of those Kepler deployment stuffs.“ I am also open for that. Just want to check whether there is still scenario where only helm chart is needed to deploy kelper?
3. ”deploy kepler in multiple-nodes Kubernetes clusters“. We can find such environment to improve helm chart deployment experience.

[jiere]

1. So far, it there known issue with this guide?

Please start to check if #34 has already been fixed already, if so, we can close it first.

And there are further comments from our customers when they compared the Deploy using Manifests section and Deploy using Helm Chart section description, customers especially showed great interest and focus on the integration of Kepler and kube-prometheus stack, they want 100% automatically deployment of both and make the observability feature ready after deployment. I had some sync with Sunil before on this, it seems that Openshift is good at this, unfortunately our customers do not deploy Openshift yet.

2. Just want to check whether there is still scenario where only helm chart is needed to deploy kelper?

This should be specific customers/users' requirement, in case they always enjoy the experience of Helm in other projects and expect kepler also good here :)

For our Kepler community, we can support various kinds of deployment in parallel, such redundancy is acceptable, since different customer has different preference. But if one is apparently easier and more smooth than the other, we should choose the easier one.

3. We can find such environment to improve helm chart deployment experience.

We have such environment locally, we can collaborate to make it happen later :-)

[jichenjc]

I am also open for that. Just want to check whether there is still scenario where only helm chart is needed to deploy kelper?

at least I think it will be an option that we keep for some time :)

[sthaha]

Currently, deploying kepler-operator easily requires OLM which is usually not used on vanilla k8s. I think having a helm chart makes it is easier to deploy operator on vanilla k8s, so that is something we will put some effort into. In relation to replacing how kepler is deployed, I think we should provide both options until there is a clear winner.

Today, kepler helm chart may be able to do most of the work done by operator however, even with kepler deployment
kubectl get kepler -w already provides an easier way to find the status of kepler deployment and to see if it available.

My experience with operators has been that they provide more value for day-2 operations. E.g. upgrade kepler to new image, modify configmap of previous version to use newer one (may be change to use xgboost).

In summary, we don't have to decide now the "right" way to deploy kepler. Lets provide all options until there is a clear redundancy that we can avoid.