Closed romayalon closed 4 years ago
@copejon @jeffvance Would love to get your input on this We would like to fix this and would love to get your inputs
Will take a look now.
@romayalon What version of the library are you running? I'm having trouble reproducing this on master:HEAD. This was a known issue that was only fixed in the last couple commits.
@copejon referencing the BZ https://bugzilla.redhat.com/show_bug.cgi?id=1785260#c4
@nimrod-becker Thank you, that should give a better picture of what's going on. I'll read & test and let you know what I find.
@nimrod-becker @romayalon It seems like there are 2 issues described in the BZ:
1 - deleting an erroneous OBC and recreating it causes creation to take an unexpectedly long time. The bug was that obc keys were not being dropped from the queue on deletes. #184 fixes this. Please update the noobaa operator's version of the library.
2 - That OBCs whose storageClasses don't exist are retried on an exponential backoff. This is a desired behavior of k8s controllers - to make a best effort to make Actual State of the World == Desired State of the World. However, the user isn't informed of what's going on, which is a deficiency on our part. #68 needs to be addressed here
Updated lib-bucket-provisioner to the latest version and now it works as expected. Also i've added errors in NooBaa for the specific bug. Thanks
good new @romayalon ! I'll close this issue.
lib-bucket-provisioner should make sure to remove OBC's from the queue when they are deleted. scenario: when creating a faulty OBC, the provisioning do not succeed, after deleting the OBC, the next correct OBC creation takes a lot of time. Suggested fix: The queue should also contain the UID too so that delete-create will not reuse the same item.