freenas-provisioner: Broken in FreeNAS 11.3-RELEASE
Seems FreeNAS v11.3-RELEASE changed the capacity to IEC Suffixes. New PVC yield the error:
I0212 04:58:09.995962 1 event.go:221] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"test", Name:"test-config", UID:"9f22bf96-256f-405f-adc4-9f6bb5ca373f", APIVersion:"v1", ResourceVersion:"1431038", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' failed to provision volume with StorageClass "freenas-nfs": Error creating dataset "tank/Kubernetes/test/test-config" - message: {"refquota":["Specify the value with IEC suffixes, e.g. 10 GiB"]}, status: 400
This happens when setting spec.resources.requests.storage to nG and nGi.
Does this need to suffix the value with B?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 34 (1 by maintainers)
The default yaml is still pointing to an older version. Try updating to
2.6and see how it goes.Ok, iscsi with csi with
rkeorranchercan be tricky so just wanted to make sure you were set on that.That’s fair about ssh, I had several other reasons as well for example it will work with any zfs based solution very easily…(ie with very little extra code it supports any generic ZoL install such as Ubuntu to rhel). Also, I’m doing some fairly advanced stuff with zfs properties, clones, snapshots, zfs send/receive, etc that simply don’t exist now in their API and likely never will (unless they create a generic API method to allow arbitrary shell exec).
In any case, the project was built to generally support many ‘drivers’ anyhow so a pure HTTP FreeNAS driver theoretically could be added for sure if there’s need/interest. I’m planning to create another zfs driver for ephemeral volumes for example when I get a little extra time.
I’m running FreeNAS 11.3U5 and freenas-provisioner 2.6 and I’m getting the following error when provisioning the pvc in test-claim.pvc:
I ran a tcpdump and confirmed the JSON in the HTTP Post is not appending ‘B’ to the quota. Here is the JSON I got from the Post in the capture:
The only changes I made was to increase the storage size to ‘1Gi’ in test-claim.yaml due to the minimum quota value in FreeNAS 11.3, and I also set datasetEnableReservation to false in class.yaml because I don’t want a reservation.
Should this be closed? The failure still occurs when the default configuration is used (reservations and quotas enabled). Is there another issue to track that?
@nmaupu agreed on the API changing madness! That’s one of the many reasons I decided to go with raw zfs commands over ssh with the csi project…the surface area of API calls there is very limited.
The version stuff is OK, but as I mentioned the version strings returned over the years from the API are madness as well. My vote would be to merge what we have above and just run with it. If issues come up for older versions then address them if necessary.
The csi driver is ready to go if you’re waiting for something there’s no need to wait.
I wondered if other values would exhibit the same issue. Good to know. I’ll fix up a patch with that field included as well. Not sure about commiting at this point. I need to try that against some older FreeNAS versions to make sure we’re not breaking something in the other direction. If it works going back then I’d have no issue commiting it personally. I would assume it works going back to pretty old versions, but I’ve learned not to assume anything with the FreeNAS API 😦
I’ll update my test system to 11.3 and do some trial and error and see what I can find. It’s really unfortunate they keep making changes like this making it difficult to maintain sanity across versions 😦
In the csi driver all the zfs operations are done via the cli over ssh so this kind of garbage should be highly mitigated.