This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illusrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and leads to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally ignoring the teardown network when error is related to CNI
initialization, while allowing teardown retry to happen when it makes
sense.

This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illustrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and can lead to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally ignoring the teardown network when error is related to CNI
initialization, while allowing teardown retry to happen when it makes
sense.

This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illustrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and can lead to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally ignoring the teardown network when error is related to CNI
initialization, while allowing teardown retry to happen when it makes
sense.

Signed-off-by: Zihong Zheng <zihongz@google.com>

This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illustrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and can lead to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally ignoring the teardown network when error is related to CNI
initialization, while allowing teardown retry to happen when it makes
sense.

Signed-off-by: Zihong Zheng <zihongz@google.com>

This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illustrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and can lead to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally skipping the teardown network only when error is related
to CNI initialization, while allowing teardown retry to happen if setup
already allocated network resoruce partially.

Signed-off-by: Zihong Zheng <zihongz@google.com>

This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illustrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and can lead to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally skipping the teardown network only when error is related
to CNI initialization, while allowing teardown retry to happen if setup
already allocated network resoruce partially.

Signed-off-by: Zihong Zheng <zihongz@google.com>

This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illustrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and can lead to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally skipping the teardown network only when error is related
to CNI initialization, while allowing teardown retry to happen if setup
already allocated network resoruce partially.

Signed-off-by: Zihong Zheng <zihongz@google.com>

This is a follow up of both containerd#10744 and containerd#10839, where teardownPodNetwork
may be skipped if setup networks failed in the first place.

In the situation illustrated on containerd#12130, for chained CNI pattern the
skipping logic may be problematic and can lead to network resource
leakage (e.g. Pod IP).

This PR attempts to make the sandbox network handling more robust by
conditionally skipping the teardown network only when error is related
to CNI initialization, while allowing teardown retry to happen if setup
already allocated network resoruce partially.

Signed-off-by: Zihong Zheng <zihongz@google.com>