Some issues for deploying Kepler by kepler-helm-chart.

[jiere]

When I followed README here to deploy Kepler, Kepler could be normally deployed and we could fetch metrics by port forwarding 9102 port. However, I still had several concerns as follows:

1. I deployed Kepler on local kind cluster which was created by running make cluster-up command under local kepler source code repo. After helm install kepler, I used helm list to check the release info, but found nothing, so how could I helm uninstall kepler then? See test console logs:

$ helm repo list
NAME    URL
kepler  https://sustainable-computing-io.github.io/kepler-helm-chart
$
$ helm list
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION
$
$ kubectl get pods -n kepler
NAME           READY   STATUS    RESTARTS   AGE
kepler-2s9tv   1/1     Running   0          3h28m

2. After deployed Kepler, we could see that the service name is kepler, however, when deploy Kepler from source code, the default service name is kepler-exporter, it's better to make the name consistent among different deployment methods.

3. In Chart, the current version is 0.4.0, and the current appVersion is release-0.5, this looks confused to customers. May I know the history and consideration here?

[jiangphcn]

Good catch! I will get time this week to look into them.

[yellowhat]

1. May I ask to document the entire process? I think helm install kepler creates an empty release (never tried myself), could you try as suggested in the README helm install kepler kepler/kepler?

2. Are you referring to a serviceMonitor custom resource

• version refers to the helm chart version
• appVersion is something that to the application version, in this case we are using it also the define the container image tag.

I have already opened a issue about this.
TLDR: having a image tag release-X is no good.

[jiere]

1. could you try as suggested in the README helm install kepler kepler/kepler

I just used this command, exactly followed README.

[yellowhat]

In that case may I ask to recreate your cluster from scratch and document all the steps?

Thanks

[jiere]

kepler-helm-chart-deploy.log
@yellowhat , pls check the log.
No special steps, just document like this:
Step 1: create local kind cluster using kepler's make cluster-up command;
Step 2: follow README to run command: helm install kepler kepler/kepler --namespace kepler --create-namespace;
Step 3: wait for kepler pod running, then check the kepler svc and check the helm list.

[yellowhat]

Ahhhhhhhhhhhhhhhhhhhhhhh.
helm list will list only the installation of the current namespace.
Could you try helm list -A or helm list -n kepler?

[jiere]

helm list will list only the installation of the current namespace.

Sorry, my bad :-(
Please ignore item#1 in my original description then.

[jiere]

2. Are you referring to a serviceMonitor custom resource

Not exactly. I just used kubectl get svc -n kepler to check.
In my point of view, consistent naming among different deployment scenarios makes automation easy:)

[yellowhat]

That's a good point, I agree with you: we should pick a name kepler or kepler-exporter, and be consistent between the helm chart and the main page.

From my point of view:

• the name of the project is kepler
• adding the name -exporter would add more character that I would have to parse in my mind without adding any value

@rootfs what do you think?

[jiere]

Just had a check on kepler-operator side, 3rd phenomenon appeared there...
Let me summarize (all by default behavior):

• deploy from kepler source.
  namespace: kepler
  svc name: kepler-exporter
• deploy from kepler-helm-chart.
  namespace: kepler
  svc name: kepler
• deploy from kepler-operator.
  namespace: default
  svc name: kepler-exporter. (under the same "default" namespace, there is another svc called kepler-model-server by default)

[yellowhat]

Great summary

[rootfs]

@jiere nice job!

We need some consistency. Would kepler or kepler-system work? This will work for both kepler the daemonset and model server deployment.

cc @husky-parul for operator.

[husky-parul]

Just had a check on kepler-operator side, 3rd phenomenon appeared there... Let me summarize (all by default behavior):

• deploy from kepler source.
  namespace: kepler
  svc name: kepler-exporter
• deploy from kepler-helm-chart.
  namespace: kepler
  svc name: kepler
• deploy from kepler-operator.
  namespace: default
  svc name: kepler-exporter. (under the same "default" namespace, there is another svc called kepler-model-server by default)

Great discussion. kepler-operator is following the same naming conventions as when deployed from source. We definitely need consistency across all deployment scenarios (100% agree on this). But I will bring some context here.

1. kepler-exporter was the choice because we have other components in the Kepler ecosystem like kepler-model-server and kepler-estimator It was to identify what components we are talking about specifically (metrics exporter/model server/estimator). We can defer to kepler as the name when we are referring to the kepler metrics exporter service.

2. How kepler-operator namespace is decided is inconsistent. For e.g. if we use OperatorHub on OpenShift console the operator gets installed in the namespace openshift-operators. If you run via the source make deploy IMG=<> it gets installed in kepler-operator-system

@jiere Could you please elaborate the deployment step that led to the installation in default ?

Thanks.

[jiere]

Could you please elaborate the deployment step that led to the installation in default ?

@husky-parul , please see my deployment result after following guide here:

default kepler-exporter-db4nd 1/1 Running 0 4h10m
default kepler-model-server-5d5fcf64cc-qlnjx 1/1 Running 0 4h10m
kepler-operator-system kepler-operator-controller-manager-7fc984ff77-psk5b 2/2 Running 3 (3h5m ago) 4h12m

BTW, in this step, I used these commands as the guide says:

make deploy IMG=quay.io/sustainable_computing_io/kepler-operator:latest
kubectl apply -k config/samples/

I agree that there might be different namespace naming between kepler-operator-system and openshift-operators, but they both are namespaces for the operator itself.

What we are talking in this issue and related issue on operator repo side is: the kepler svc itself naming and its namespace's naming.

I also agree that kepler-exporter makes it more accurate and meaningful when it stands with kepler-model-server and kepler-estimator at the same time.

From my personal point of view, my vote is like this(keep consistent among different deployment: source/helm/operator):
namespace: kepler
service name: kepler-exporter, kepler-model-server, kepler-estimator