Deploying customised Kubeflow component

charm
#1

As Kubeflow and all of its components are fully opensourced, I have ideas to make them more fit my usecase.

But I am a still new to the juju/charms ecosystem and was wondering how should I approach deploying customised components.

For demonstration purposes, let’s say I want to change color of the Kubeflow dashboard from blue to green.

I assume I would have to change the charm bundle to exclude the https://charmhub.io/kubeflow-dashboard and substitude it with some local edited copy from 1.7 branch of https://github.com/kubeflow/kubeflow/tree/v1.7-branch/components/centraldashboard , but no idea if that is the correct approach or how to even make it work.

Any help/pointers would be appreciated.
Crispy

#2

Hi Pavel, part of the advantage of using the Charmed version of Kubeflow is you can get up and running very quickly out of the box. We provide sensible default configurations and the ability to configure some common things.

Your idea sounds it may work and would be interesting to see how it turns out. But I’m interested to know what your actual use case is? Are you running Kubeflow in production, or are you a hobbyist just trying it out for learning? Or something else?

#3

Thank you kindly for the response.

We are currently in exploratory phase for setting up a mid-sized AI Lab. Kubeflow is the strongest candidate so far as it allows team separation/colaboration. The reason to go with charmed Kubeflow is mainly driven by the enterprise support.

Currently there is no specific usecase that would be a dealbreaker, but we expect systems like private MLFlow server per namespace to require additional hooks to the event system. The ability to fix the some bugs ourselves would be also a great benefit as waiting for next release might slow us down.

We see the ability to edit the source to be quite important, but the process of doing so seems to be unclear. If you have any theoretical or practical tips we could explore to see if deploying our version of components is a viable strategy, we would be delighted.

#4

Hey thanks for this information it’s really useful.

So I think what you’re saying is, you want Charmed Kubeflow (as opposed to raw, upstream Kubeflow) because of the enterprise support. But, at the same time, you want to be able to diverge from the official charmed Kubeflow and make your own customisations or bugfixes.

It’s a good question. Let me bring this up with our product manager and the engineering team.

#5

Thank you for reaching out to the other teams.

Yes, that is correct. I also wanted to note that we fully understand that the support will exclude any modified components, but it is always good to know that we can fallback on the official packages with support.

#6

Hey @pavkon yes I discussed this with @munteanuandreea (our PM) and others. The general consensus is that we don’t recommend modifications to the source code. As you can understand, this means we haven’t invested any time in documenting how to modify the source code as you say.

What we do strongly encourage though is contributions. If you do find a bug, then we would really appreciate a PR. And if you have an idea for a feature request, reach out to us on Mattermost or raise a GitHub issue :slight_smile: and the team will discuss.

In terms of prioritising issues, as I’m sure you understand, we will prioritise the issues that the team feels are critical, and we will also prioritise requests made by our customers.

2 Likes