| Re: [che-dev] (no subject) |
User(administrator Che installation) could provision persisted volumes with storage class names. Then user(administrator) can start new che installation with class names and Che PVC(s) will be bind to created persisted volumes. I tested such Che configuration and it works without che-server and che-operator modification. I prepared new pr for chectl che-incubator/chectl#461
Also we can cover storage class names properties using helm installer #15677Also I prepared doc:
eclipse/che-docs#1039I believe these pr's it is technical minimum to resolve issue with host volume path without awaiting on minikube enhancements.
@sleshchenko thanks a lot for consultation about PVC configuration Eclipse Che.
_______________________________________________On Fri, Jan 10, 2020 at 2:21 PM Oleksandr Andriienko <oandriie@xxxxxxxxxx> wrote:I took a look pr's in the minikube. So actually minikube has 3 related pull requests:
https://github.com/kubernetes/minikube/pull/5400 -> pvc folder path readability
https://github.com/kubernetes/minikube/pull/6156 -> resolves our issue, by customizing host volume path. Work stopped due 2 months. And Ci test fails.https://github.com/kubernetes/minikube/pull/6257 -> this one should fix ci issue for storage provisioner component.
I think we should temporarily stop work on the issue https://github.com/eclipse/che/issues/15157 , while ci check for storage provisioner will be fixed https://github.com/kubernetes/minikube/pull/6257, and than if main interesting pr https://github.com/kubernetes/minikube/pull/6156/files won't be handled by kubernetes team we can help complete it.On Fri, Jan 10, 2020 at 1:21 PM Serhii Leshchenko <sleshche@xxxxxxxxxx> wrote:Yeah, the good news that there is activity related to the issue our users faced,Actually they are trying to solve another issue - pvc folder path readability, but it would solve our issue as well.Bad news that the author is not able to finish his PR soon.So, I personally like more idea to invest time into fixing minikube issue andbuilding workarounds on Che side which cost quite a lot.On Fri, Jan 10, 2020 at 12:53 PM Oleksandr Andriienko <oandriie@xxxxxxxxxx> wrote:Wow, I see an issue about configurable default host volume path for minikube https://github.com/kubernetes/minikube/issues/5144 and pr was created https://github.com/kubernetes/minikube/pull/5400_______________________________________________On Fri, Jan 10, 2020 at 11:53 AM Oleksandr Andriienko <oandriie@xxxxxxxxxx> wrote:_______________________________________________Hello, I am from Deploy Team and I am working on issue[1] and I would like to discuss it. User asks for implementing for chectl an ability to configurе Eclipse Che host volume paths. Why do we need this change? User can deploy Eclipse Che on the minikube locally(without virtual machine, it is an option "minikube start ...options... --vm-driver=none"). Also user can deploy Eclipse Che on the LXD container with pre-installed minikube(without VM too, because LXD container it is a light alternative VM). Minikube has hard-coded host volume path to the /tmp/hostpath-provisioner folder. So if application(like Eclipse Che) doesn't create own persisted volume, then minikube provide volumes from `tmp` folder. When user restart computer or lxd container, Eclipse Che loses all volume data with postgres DB and workspaces source code, because system clean up `/tmp` folder. Options to solve user's issue: 1. It seems to be not really Che issue but minikube since Kubernetes declares that persistent volumes must keep data even after Deployment or Cluster restart. So, quite logical proposal here could be provide an ability for minikube to configure root folder for PVs, now it's hard-coded to /tmp/hostpath-provisioner[2]. But it's more long term solution since it needs participation of minikube team and minikube release then. 2. As an alternative solution (it's even more workaround) - implement the option user asks for: Che could try to manage host paths manually instead of relying on default minikube hostpath-provisioner. I've already created pull request[3] to the che-operator to fix this issue for Postgres DB where Che Operator creates Persisted Volume with non /tmp path and then reference it from Persistent Volume Claim for postgres. But more difficult part here is Che Server part, Che Server itself doesn't need persisted volumes, but they're needed by Workspaces. So Che Server can create persistent volume(PV) per workspace/per user and bind Persistent Volume Claim to pre-created PV by class name. And questions here: - then Che Server would need cluster-admin rights, now for K8s platform it has but I heard willing that we want to get rid of it; - then Che Server would do additional logic with managing PV, except preparing we should also think about cleaning them up after workspace removing. So, do we really need such quite fast but dirty solution to workaround platform issue? It seems it costs for us quite much to implement it and later support. Before creating an issue for minikube and initing such discussion there I would like to hear opinions [1] https://github.com/eclipse/che/issues/15157 [2] https://github.com/kubernetes/minikube/blob/master/pkg/storage/storage_provisioner.go#L50 [3] https://github.com/eclipse/che-operator/pull/144
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev