Install renku with helm charts being locally available

Renku Admin
1

Hi Team,
if I do not want to install renku (and depending services) from public helm repo, but from having the helm charts locally available…what do I have to do for that?

  • cloning which repos ?
  • preparation / configuration ?
    so that at the end I could execute

helm upgrade --install renku ./renku -n renku -f renku-values.yaml

pickung up everything from below local folder

Many thanks in advance and best regards
Gerd

2

Hi @gkoenig! Do you want to use just the charts from source or also build the images for all the services? We have a script that will sort of do this for you - you can specify a version of each component to deploy and it will check out that component’s repository, build the component, and modify the requirements.yaml file to point to the correct chart on disk. We use this script for testing during development. The problem is that at the moment it will always push the images to our renku docker hub repository so this part of the script would need to be changed. It also doesn’t currently allow you to point to an existing location on disk - it always clones the repo and checks out the ref that you specify. Both of these shortcomings could be addressed, but I’m wondering if you can specify in a bit more detail what sort of use-case you have in mind?

3

Thanks for your immediate reply @rrrrrok
What your script does sounds already very promising. At the end I am interested in e.g. editing the container templates for extended troubleshooting.
I’d be fine if the images are pushed-to&pulled-from your dockerhub repo , hopefully I am able to do so in an enterprise environment…but that’s another story.

To me it looks like the only change would be, that it doesn’t clone the repos but instead takes it from a local dir

Best
Gerd

4

At the end I am interested in e.g. editing the container templates for extended troubleshooting.

I see, so some sort of “debug” mode? Do you have something generic in mind? If so, we could add it to the component charts themselves. We already do something along these lines for the renku-core service (see here and here). If it’s a one-off debugging effort, I usually just modify the deployment manifest directly using kubectl.

To me it looks like the only change would be, that it doesn’t clone the repos but instead takes it from a local dir

Indeed, this would be a very welcome addition :wink:

5

let me rephrase, since my wording of “container template” was a bit misleading.
I’d be happy to have the possibility of editing the “kubernetes resources templates” which are used by the helm install, at the end I do not need to rebuild the images themselves.
Just as an example: if a pod is in a CrashLoopBackoff situation, I’d like to edit the entrypoint to something like “sleep 3600”, to be able to start the pod and grab a shell for further debugging.
Makes sense ?

Best regards
Gerd

6

Hi @gkoenig, not sure if this helps but my dev flow with renku is as follows:

  • Clone the renku repo
  • Clone any of the repos that are tied to the renku requirements
  • Run chartpress (i.e. pipenv run chartpress) in any of the repos for the renku requirements you wish to modify (i.e. insert sleep statements in), chartpress will build the docker images for that repo and also tag a new chart version
  • Update the renku requirements.yaml file to point to the helm chart locally that you just modified. For example for renku-notebooks if you have the repo cloned in the same parent folder as renku then the path in the requirements file needs to be file://../../../renku-notebooks/helm-chart/renku-notebooks/.
  • Update the chart version in the renku requirements file to match the new version tagged by chartpress in the component repo - you can find this in the Chart.yaml file in the component repo.
  • After you have modified, built and tagged all requirements that you wish to change then run helm dep update helm-chart/renku in the renku repo and then run helm install ...
  • When you change a component you have to rerun chartpress for it, update the chart version in the requirements file, run helm dep update and then helm upgrade ...

But I rarely have to insert sleep statements in the different components to debug. Usually a simple kubectl logs ... will give enough information on what the problem is.

Hopefully this helps. Let me know if you want me to post all the links to the repos of components in the renku requirements file.

Disclaimer: these steps will probably not work on the two components that we do not directly maintain (keycloak, postgress) or with the gitlab chart.

1 Like
7

Just as an example: if a pod is in a CrashLoopBackoff situation, I’d like to edit the entrypoint to something like “sleep 3600”, to be able to start the pod and grab a shell for further debugging.

Sure, that makes sense - for these kinds of one-off debug sessions, I just do kubectl edit deployment and insert whatever changes I want to the container spec. Personally I’ve found that to be far easier then editing the helm templates and redeploying from a local chart, but I’m sure there could be situations in which your approach would be more convenient (and possibly result in less typing :slight_smile: )

1 Like
8

Thanks @rrrrrok / @tolevski
I’ll give both approaches a try, due to lazyness the kubectl edit... approach will win for the quick run :smiley: