Kubeflow charms are still requesting PVC for each charm

[jameinel]

See original bug report here:
https://bugs.launchpad.net/juju/+bug/1959886

Since juju 2.8, charms can set 'min-juju-version: 2.8' for metadata v1 charms, or just be metadata v2 charms. With either of those things set, they can use state-set and state-get to set key-value pairs in the Juju controller, rather than relying on the local disk to be persistent. (Operator Framework should already be updated to use state-set/get when it is available rather than the local disk.)

I don't know if the kubeflow charms even need persistent state, but they do need to be updated to indicate that they don't.

The issue for field is that without those settings, it means that each application in kubeflow ends up consuming another PVC, and you can't just deploy kubeflow to a large instance (because you run out of available mount points).

[ca-scribner]

Thanks @jameinel, this is really helpful. There's a few things we misunderstood here that are much clearer now. Almost (maybe all) of our charms have no need for stored state, and definitely not stored state that is outside the controller, so we can address this.

Am I understanding correctly then that if we do either of min-juju-version: 2.8 or make metadata v2, by default juju will not create a pvc for stored state and instead write to the controller? Or is there an extra option we need to use to avoid the new PVC being created?

[jameinel]

If you set those things, juju won't create a PVC for the charm. The juju agent itself already uses the controller for state, but if your charm is trying to use a charmhelpers.keyvalue store or something like that, those are built on a local sqlite database, which means that if the charm pod ever got rescheduled, all of that data is gone. So *I* can't say what your charm is/isn't writing, but Juju itself doesn't need the PVC.

…

On Fri, Feb 4, 2022 at 9:40 AM Andrew Scribner ***@***.***> wrote: Thanks @jameinel <https://github.com/jameinel>, this is really helpful. There's a few things we misunderstood here that are much clearer now. Almost (maybe all) of our charms have no need for stored state, and definitely not stored state that is outside the controller, so we can address this. Am I understanding correctly then that if we do either of min-juju-version: 2.8 or make metadata v2, by default juju will not create a pvc for stored state and instead write to the controller? Or is there an extra option we need to use to avoid the new PVC being created? — Reply to this email directly, view it on GitHub <#425 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRQ7MY4B5KVTRHVLMXVPLUZPQMDANCNFSM5NR4NRFA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[phvalguima]

Hi, I've done some tests and using: min-juju-version: '2.9.0' indeed resolve this issue.

[VariableDeclared]

First set of changes: canonical/kfp-operators#60

[VariableDeclared]

Added remaining changes. Although there is an issue with istio metadata which I am trying to understand. PRs below:

Kubeflow dashboard: canonical/kubeflow-dashboard-operator#25
Kubeflow profiles: canonical/kubeflow-profiles-operator#26
Tensorboard PR: canonical/kubeflow-tensorboards-operator#10
katib PR: kubeflow/katib#1804
jupyter PR: canonical/notebook-operators#27
Argo Operators: canonical/argo-operators#24

[VariableDeclared]

Next batch:

MLFLow: canonical/mlflow-operator#12
Istio: canonical/istio-operators#57
Minio: canonical/minio-operator#34