Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sairameshv

The full list of commands accepted by this bot can be found here.

The pull request process is described here

@sairameshv not sure if I got this correctly, but reading this comment #336 (comment) I get the impression that if we inject the code in deamonset to delete all allocations during the deamonset bootstrap, would it fix the issue?

by that I meant, what happens if you fetch the corresponding instaslice object and delete all allocations somewhere here, https://github.com/openshift/instaslice-operator/blob/main/internal/controller/daemonset/instaslice_daemonset.go#L98 ?

by that I meant, what happens if you fetch the corresponding instaslice object and delete all allocations somewhere here, https://github.com/openshift/instaslice-operator/blob/main/internal/controller/daemonset/instaslice_daemonset.go#L98 ?

If we delete all the previous allocations when a daemonset comes up after a reboot, can we gate the pods again and create the slices ? Any thoughts @asm582 ?

by that I meant, what happens if you fetch the corresponding instaslice object and delete all allocations somewhere here, https://github.com/openshift/instaslice-operator/blob/main/internal/controller/daemonset/instaslice_daemonset.go#L98 ?

If we delete all the previous allocations when a daemonset comes up after a reboot, can we gate the pods again and create the slices ? Any thoughts @asm582 ?

good point, all partitions will be deleted by the hardware after reboot. I think if an operator or deployment is used to spawn pods, then we will always have new ungated pods. we need to come up with a solution for plain pods.