No default storageclass is set with the default install

[woopla]

After the Docker cleanup fix in #83 I got a cluster up and running, nice!

Well, almost, because all the services that require storage could not start since they were waiting for PVCs to be filled. This is because there's no default storage class. Fixing it is as simple as running:

kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Could you please change the flow so it sets the first StorageClass it finds as default?

[ralgozino]

Hi @woopla, thanks for the feedback!

I personally don't think that setting a default storageClass is in the scope of the on-prem installer. It is not granted that the end-user wants that.

You can though set the local-path provisioner as the default storageClass when installing it. If you are using plain yaml manifests add the annotattoins to you yaml definition, or with Kustomize, putting something like this in you kustomization.yaml file:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - "https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.27/deploy/local-path-storage.yaml"

patches:
  - patch: |
      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: local-path
        annotations:
          "storageclass.kubernetes.io/is-default-class": "true"

[ralgozino]

I forgot to mention, have you tried using furyctl?

https://docs.kubernetesfury.com/docs/furyctl/how-it-works/how-it-works
https://docs.kubernetesfury.com/docs/quickstart/fury-on-vms

[woopla]

Thanks @ralgozino. I've setup the cluster using furyctl and followed the fury-on-vms quickstart. That's why I'm surprised there's no mention that you need to setup a default storageClass when using the standard furyctl.yaml - I've tried both the pre-generated one in https://github.com/sighupio/fury-getting-started/tree/main/fury-on-vms and one I generated with https://github.com/sighupio/fury-getting-started/tree/main/fury-on-vms.

Regarding the use of a kustomization.yaml file, I think the docs could use a bit more explanation as to how you do that - where do you put the file for furyctl to find it, for example? I´d say https://docs.kubernetesfury.com/docs/furyctl/how-it-works/how-it-works would be a good location for that info.

Don´t get me wrong, I think KFD is great, I'm just trying to get situated :D BTW, I was able to get it to work with Kind by following the Minikube tutorial - I´d like to be able to replicate the production system architecture (that is going to use VMs) but with a Kind "cluster" on a single VM for testing.

[ralgozino]

Hey @woopla, sorry for the delay

I've setup the cluster using furyctl and followed the fury-on-vms quickstart. That's why I'm surprised there's no mention that you need to setup a default storageClass when using the standard furyctl.yaml - I've tried both the pre-generated one in https://github.com/sighupio/fury-getting-started/tree/main/fury-on-vms and one I generated with https://github.com/sighupio/fury-getting-started/tree/main/fury-on-vms.

oh cool! I though you were using the on-prem installer without furyctl. Thanks for the feedback, we should say that in the docs. I'll fix that.

Regarding the use of a kustomization.yaml file, I think the docs could use a bit more explanation as to how you do that - where do you put the file for furyctl to find it, for example? I´d say https://docs.kubernetesfury.com/docs/furyctl/how-it-works/how-it-works would be a good location for that info.

My previous advise was based on thinking that you were following a more manual way, I did not know you were using furyctl (nor the fury-on-vms guide). We'll improve the guide to make the local storage class the default one.

You can install plugins that take a helm chart or a kustomize project (a folder with a kustomization.yaml file) and instruct furyctl to install them by adding them to the .spec.plugins section of the furyctl.yaml file.

Don´t get me wrong, I think KFD is great, I'm just trying to get situated :D BTW, I was able to get it to work with Kind by following the Minikube tutorial - I´d like to be able to replicate the production system architecture (that is going to use VMs) but with a Kind "cluster" on a single VM for testing.

That's great to hear! thank you and keep the feedback coming :)

[woopla]

Thanks for the feedback @ralgozino !

For the kustomization.yaml file, I got confused because I'm looking at both the furyctl side of things and the distirbution docs at the same time, so I was thinking, "maybe it's possible to specify a kustomization.yaml file inside furyctl.yaml so furyctl will put in in the right place before installing the distribution piece.".

Looking at a furyctl-generated YAML, I see a commented out spec.distribution.customPatches section, but I couldn't find docs on how to use that. The stuff @ https://docs.kubernetesfury.com/docs/furyctl/providers/onpremises/#specdistributioncustompatches is pretty dry :)

[ralgozino]

Yes, you can patch the distribution using kustomize syntax in the customPatches section. Just like you would in a kustomization.yaml file. You can use strategic merge, JSON patch, configMap and Secrets generators and the images directive and it would be applied to all the distribution manifests.

I agree that the specs docs needs a lot of improvement.

For setting the local path provisioner as the default storage class you can see my linked PR:

• docs(fury-on-vms): set local-path as default storage class fury-getting-started#51