Gitops Config managing itself creates race condition that will delete all resources about eunomia HOT 3 CLOSED

Since multiple jobs had kicked off for the same GitOpsConfig by one webhook and the GitOpsConfig was managing itself. I believe that one of the jobs updated the timestamps while the other job was running thus deleting the owned Kind of GitOpsConfig that had a different timestamp than it was expecting.

The deletion logic does have problems when jobs overlap. We are mitigating this, in part at least, via #351 but we need a long term solution that can make the individual jobs idempotent or use a locking mechanism so that they are able to run concurrently if that case arises.

So once the gitopsConfig was deleted then all of the other resources were deleted as well.

An option would be setting resource deletion mode to None which abandons resources managed by a gitopsConfig when that gitopsConfig is removed. Not ideal but its something...

from eunomia.

@sanbornick found a way to fix this ... https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency

from eunomia.

Fixed by #376.

from eunomia.