-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ProvisioningFailed - IntegrityError: UNIQUE constraint failed: #8
Comments
Are you just starting out with this? Or do you already have stuff provisioned? |
Just starting, why? Better options? |
Yes, my next gen version of this is available over here:
I guess I should know what version of k8s you're on and what distro of k8s you use as well. To address the actual issue, I'm guessing you'll hit the same problem. I've seen some weird database issues with FreeNAS before (had nothing to do with either provisioner) where invalid entries weren't cleaned up properly perhaps even from using the UI. They could have stemmed from 11.1 like you're using but not entirely sure. In any case, if you can run the other project let's get you moved over to that and I'll send some info in a bit with how I cleaned up the DB in the past manually. |
Cool, appreciate the response and honestly open to suggestions. A bit of background, I'm currently running "all-in-one" with FreeNAS virtualized (HBA passthrough) on a single esxi (free license) host. My lab mostly runs home prod stuff (plex and the like, home automation, etc). VMs are running RancherOS and I used Rancher for setting up the k8s cluster, I was on 1.13 and just upgraded it all to 1.15 and will keep working up. If I can figure out best re-architecture of my storage I'll likely rebuild and just copy data over. Currently I've been playing with and have OpenEBS running (messed with cStor and then went back to jiva default). Even though I'm just trying to model a real setup, the problem is having 3 replicas on same hardware has redundancy < 1 since it needs at least 2 up for R/W access. I really liked the idea of baremetal k8s, but don't trust myself with the storage and otherwise don't feel like my prior 12-bay R510 or new R720xd is fully utilized if it's only used for storage. I toyed with extra servers, don't really need the power or expense, also vSAN through VMUG, rook-ceph, etc. but I keep coming back to simplicity of FreeNAS, with benefits of snapshots and easy remote backup through zsend. With decent hardware and backups seems to be reliable enough for my needs despite my fascination with HA. I use HDDs for bulk storage (media) and NVMe for local VM datastores (mostly to bootstrap FreeNAS VM and the k8s nodes). I could dedicate at least a couple NVMe passed through for fast storage (likely looped back for a couple other VMs) or keep using virtual disks to play around and just make sure they're across different drives. |
Wow! Not messing around :) Well, you're at a new enough k8s version to use csi, but you may have issues with iscsi based on containerized k8s. See this: rancher/rke#1846 I'm not sure if it's possible to achieve the fix using rancher directly with rancher os so let me know what you think. The new project supports all the fancy new stuff like snapshots etc, but snapshot support recently went beta and changed things around a bit from the alpha support I programmed for and I haven't updated to support the new stuff. It requires 1.17 anyhow I believe. It will do snapshots to another pool on the same host, but I'm considering adding support for remote snapshots which sounds like might be of interest to you. I'll give some notes on the DB issue with FreeNAS when I'm not just on my phone. |
Ok, so DON'T do this exactly (or possibly even at all). However I was constantly getting some crazy error responses from the API and it turned out to be that exact table that was messed up. I was getting some errors (don't recall exactly what) but the DB had entries that were not visible in the UI...I found it strange so started doing some digging into the DB directly and that's when I found the bogus rows. I was in a position that I could just wipe stuff and start over completely clean:
I'm not entirely sure when/how the DB got the invalid entries in there, so a different course of action may be required (I wouldn't update to |
Any more luck with this one? |
Was gone for spring break and busy. Just kind of documenting here for reference. I had another test target from a windows machine so maybe that messed up the table. I looked into the sqlite db but only see 1 entry after deleting others from webgui...
I guess the error is having a problem with uniqueness, so prob more related to the index. Here's the schema
And the index(es) aren't empty:
Anyways, I started up another fresh test instance of Freenas 11.1-U7 so I can easily blow away if needed. I deleted the class and updated the secret to point to other server, not sure what I missed. I thought I missed something simple but then realized the iscsi service doesn't really start if there's not already a valid target (which I inadvertantly did before with my windows test).
So created another test target, extent, and associated target, then I can see a new pvc created (again like before), but still have issues with the dynamic provisioner and it ends up in CrashLoopBackOff.
Updating to 11.2 in my test freenas to see if that changes anything. I was just backtracking to see if I could better understand and quickly fix, but I need to move forward with your CSI implementation, it's just not as clear to me yet, and I think I'm trying to go the opposite direction away from helm charts, other than using them as initial templates for all the various deployment, etc. yamls. |
Ok, yeah let me know how it goes and if you need help understanding what's going on with csi. I'll dig through the backtrace and see if I can figure out what's going on. |
Well, whatdayaknow, updating to 11.2-U8 and basically everything started working swimmingly. If I were to use this for a bit, I don't guess there's any upgrade path to CSI or to remap PVCs? I guess this is kinda a general concern going forward, if I update freenas or something and break the dynamic provisioning is there a (good) way to match up the dynamic PVCs without having to restore data from a backup? I've been holding up updating my main FreeNAS because I've got a local backup and remote running on older HP Microserver Gen7 with USB boot drive that seems to be chugging along with zfs send just fine. I'm afraid updates, I guess in particular new zfs features flags may make this incompatible and force updates there which would probably require SSD boot disks. So it the basic procedure for your CSI just to add the helm repo and deploy with updated values like in the freenas example file? |
Wow, I used with 11.1 quite a bit so u7 might be a dud. Couple things:
You are correct, there is no upgrade path currently between these and Yes, to deploy the |
Ok, I'll try to get the CSI driver going and ask any other relevant questions over there. I'm really curious about the exacts steps of your migration process with zfs send. I think my main concern (still learning) is accidentally blowing away data. I think I'd like to set default policy to retain rather than delete pvcs, and so I'm wondering if I redeploy something the best way to copy data from existing (old) pvc to new dynamically created one, or remap to old one. Once dynamically provisioned I see the volume claim yaml, but it's not editable, so I guess the other concern is backing up this info in the cluster, or rather be able to start a new cluster, redeploy, and remap/bring data over. For snapshots I was hoping from the freenas side I could just nightly (when things should mostly be quiescent) create a snapshot to zfs send remotely. In practice, is this not robust enough and can lead to data corruption? I'm assuming the real k8s way will temporarily pause data (scale down deployment?), tell freenas to snapshot, and then spin back up? Resizing would be a great feature, as it's something I've been concerned about particularly when I'm unsure how things will grow, so interested more on that later. For now a lot of the storage size appears fixed upon creation so I figured I'd eventually get backup/restore going to accomplish that when needed. Thanks again. |
Yeah, you can set the policy on the class and any new PVs provisioned will automatically use the new policy. You can update any existing PVs manually. Generally the steps would be:
Regarding snapshots you are more than welcome to do snapshots as you mentioned and it's a great idea. What I mean by snapshots in this context is using the k8s resources (https://kubernetes.io/docs/concepts/storage/volume-snapshots/) to create 'snapshots' via the k8s API (ie: structured resources in k8s). After you create a structured snapshot you can actually create new
When creating snapshots out-of-band or using the new snapshots features of k8s no scaling down is required. Resizing was the primary motiviator behind implementing the |
I've been looking forward to trying this out for awhile in my homelab and unifying all my storage on freenas to take care of all the various apps relying on sqlite that don't do well over NFS. Anyways, I haven't dug into this a whole lot, just hoping you can point me in the right direction or if you've moved on past FreeNAS version 11.1-U7 since I've seen other comments about 11.2 and 11.3 things changing.
From FreeNAS I see that it's created the zvol, iscsi target, extent, and associated target. From rancher gui I see the storage class but no associated PV or PVCs. I only see this error in the events when I apply the test pod. I guessing it looks more like freenas isn't returning the correct data
And I just looked at the provisioner in kube-system and t's in CrashLoopBackOff with similar messages. Attached log.
container.log
The text was updated successfully, but these errors were encountered: