Explicitly marked cascade deletion as Foreground

[skabashnyuk]

What does this PR do?

Explicitly marked cascade deletion as Foreground.
My assumption is that reason for #16512 is deleted but not garbage collected objects.

In this PR fabric8io/kubernetes-client#1742 introduced changes in delete behavior. As you can see here #16512 (comment)
Instead of {"apiVersion":"v1","kind":"DeleteOptions","orphanDependents":false} it sends now {"apiVersion":"v1","kind":"DeleteOptions","orphanDependents":true}. This issue was reported here fabric8io/kubernetes-client#1840.

After studying this code

• https://github.com/fabric8io/kubernetes-client/blob/555c3790b02b910d62f72e95350dd563c97359a8/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/base/OperationSupport.java#L221
• https://github.com/kubernetes/kubernetes/blob/c1f1b1bceb8e6dfbc0083617a25f17dd8d57340b/staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/types.go#L478-L494

I think that instead of trying to revert this behavior we should use new semantic with propagationPolicy= foreground since we don't expect some leftovers after we call delete operation. See more: https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#controlling-how-the-garbage-collector-deletes-dependents.

What issues does this PR fix or reference?

#16512

Release Notes

n/a

Docs PR

n/a

[che-bot]

✅ E2E Happy path tests succeed 🎉

See Details

• Jenkins job

• logs and configs

• Happy path tests DevFile

• image: maxura/che-server:16540

Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1)

[amisevsk]

I'm not sure the changes are necessary; the requirement for foreground deletion is for k8s <1.7 which was released mid 2017, and shipped in OKD 3.7, which is no longer supported.

I recall pod orphaning issues coming up a few times in Che's history, but I don't think propagation has been the problem.

Edit: Reading the discussion on #16512, this makes more sense, ignore the comment above. However, I worry that this is solving the problem in an indirect way. We delete secrets directly as far as I can tell -- if the root cause of this issue is that we're trying to create a workspace before the secret is deleted, we could be avoiding the issue with this PR because a foreground delete will take longer (resulting in the workspace being in a STOPPING state for a few seconds longer) -- in other words, unless the secret that isn't being deleted is owned by some other object, I don't know that this PR addresses the issue directly. I'll have to play with the changes directly.

[skabashnyuk]

CC @ibuziuk @l0rd FYI.

[che-bot]

❌ E2E Happy path tests failed ❗

See Details

• Jenkins job

• test report

• logs and configs

• Happy path tests DevFile

• image: maxura/che-server:16540

Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1)

⚠️ https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.

ℹ️ Use comment "crw-ci-test" to rerun happy path E2E test.

[dmytro-ndp]

@mshaposhnik: please, take changes from master branch with fix of Happy path tests.

[skabashnyuk]

@mshaposhnik: please, take changes from master branch with fix of Happy path tests.

@dmytro-ndp ok

[l0rd]

@skabashnyuk LGTM

[sparkoo]

make sense now

[che-bot]

✅ E2E Happy path tests succeed 🎉

See Details

• Jenkins job

• logs and configs

• Happy path tests DevFile

• image: maxura/che-server:16540

Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1)