openshift-ci-robot
commented
2 years ago @dulek: This pull request references Jira Issue OCPBUGS-198, which is valid. The bug has been moved to the POST state.
3 validation(s) were run on this bug
* bug is open, matching expected state (open) * bug target version (4.12.0) matches configured target version for branch (4.12.0) * bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)Requesting review from QA contact: /cc @eurijon
The bug has been updated to refer to the pull request using the external bug tracker.
In response to [this](https://github.com/openshift/kuryr-kubernetes/pull/691):
>We can easily imagine an user frustrated by his pod not getting deleted
>and opting to remove the finalizer from the Pod. If the cause of the
>deletion delay was the kuryr-controller being down, we end up with an
>orphaned KuryrPort. At the moment this causes crashes, which obviously
>it shouldn't. Moreover we should figure out how to clean up the Neutron
>port if that happens. This commit does so as explained below.
>
>1. KuryrPort on_present() will trigger its deletion when it detects that
> Pod does not longer exist.
>2. Turns out security_groups parameter passed to release_vif() was never
> used. I removed it from drivers and got rid of get_security_groups()
> call from on_finalize() as it's no longer necessary.
>3. When we cannot get the Pod in KuryrPort on_finalize() we attempt to
> gather info required to cleanup the KuryrPort and "mock" a Pod
> object. A precaution is added that any error from release_vif() is
> ignored in that case to make sure failed cleanup is not causing the
> system to go down.
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
dulek
MaysaMacedo
openshift-ci[bot]
openshift-cherrypick-robot
We can easily imagine an user frustrated by his pod not getting deleted and opting to remove the finalizer from the Pod. If the cause of the deletion delay was the kuryr-controller being down, we end up with an orphaned KuryrPort. At the moment this causes crashes, which obviously it shouldn't. Moreover we should figure out how to clean up the Neutron port if that happens. This commit does so as explained below.