Helm improvement

[tunacicek]

Description

helm improvement.

• Add _helper.tpl and define functions for (Chart Name, etc.)

[evegufy]

Hi @tunacicek, I think it was quite good how you used the templates before this commit.
With my comment regarding defining the templates in unique manner, I meant instead of defining chart.name it's better to dtr.name and so on, here an example.
Sorry if the commit was inspired by the portal chart, I put unique template names also on my TODO list.

[tunacicek]

@evegufy : I got it. I've made the changes, thanks.

[evegufy]

@evegufy : I got it. I've made the changes, thanks.

@tunacicek the templates look good to me now 👍

Probably not related to the templates, but when installing locally (without any additional configuration) the readiness probes for the deployment are failing:

Other than the readiness probe, everything looks fine (pod starts up), at least as far I can tell.

[tunacicek]

@evegufy : Thank you for your feedback. I checkout the branch again and run it locally. In my case, the health checks (readiness, etc.) are running successfully. I can't reproduce the behavior. It may have taken a while for the service to start.

[evegufy]

@evegufy : Thank you for your feedback. I checkout the branch again and run it locally. In my case, the health checks (readiness, etc.) are running successfully. I can't reproduce the behavior. It may have taken a while for the service to start.

@tunacicek I tested a bit more, besides on my mac also on my linux machine.
I didn't observe the behaviour on linux and noticed then that on my mac the container never had enough time to start up entirely before the probes were causing a restart.
As a short term measure, I recommend increasing the initialDelaySeconds for readinessProbe and livenessProbe to 300 seconds as that solved the issue for me.
And you should look into providing the image also for a arm64 cpu architecture, for better performance on newer macs.

[tunacicek]

@evegufy : Thank you for your feedback. I checkout the branch again and run it locally. In my case, the health checks (readiness, etc.) are running successfully. I can't reproduce the behavior. It may have taken a while for the service to start.

@tunacicek I tested a bit more, besides on my mac also on my linux machine. I didn't observe the behaviour on linux and noticed then that on my mac the container never had enough time to start up entirely before the probes were causing a restart. As a short term measure, I recommend increasing the initialDelaySeconds for readinessProbe and livenessProbe to 300 seconds as that solved the issue for me. And you should look into providing the image also for a arm64 cpu architecture, for better performance on newer macs.

@evegufy ,
for the image arm64 topic i will create a issue.
I made the values ​​for readinessProbe and livenessProbe configurable.

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud