crossplane-contrib / crossplane-contrib/provider-openstack

External resource remains when MR deleted during provider connectivity loss

Open
#150 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
68
Forks
18
PR merge metrics
No merged PRs in 30d

Description

### What happened?

We are using **Crossplane v1.20** with the **OpenStack provider** and observed the following behavior:

- A managed resource (MR) is created via Crossplane for an external resource in the provider.
- We simulate a connectivity loss between the provider controller (in Kubernetes) and the external provider API (for example, by blocking network access via `iptables`).
- While connectivity is lost, we delete the MR in Kubernetes (`kubectl delete `).
- The MR object disappears from Kubernetes / Crossplane, but the corresponding external resource remains in the provider’s environment.
- **Result:** An orphaned external resource and inconsistency between the desired state (Kubernetes) and the actual state (provider).

This behavior was verified with multiple providers (OpenStack and VCD), so it may indicate a common deletion logic issue in the provider runtime when network connectivity is interrupted.

---

### How can we reproduce it?

1. Deploy Crossplane and configure the provider.
2. Create a managed resource via the provider (e.g., a network, volume, or VM).
3. Force a loss of connectivity from the provider controller to the external provider (e.g., using `iptables` or firewall rules).
4. Delete the MR in Kubernetes.
5. Observe that the MR is removed locally but the external resource remains active in the provider.

### Expected behavior

The managed resource should **not be deleted locally** until Crossplane confirms that the external resource has been successfully deleted, or should remain in a “Deleting” state with a condition indicating that connectivity to the provider is lost.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the managed-resource deletion while connectivity between the provider controller and external API is blocked with firewall rules such as iptables. Inspect the provider runtime's deletion behavior and compare Kubernetes state with the external resource. Done means a failed deletion leaves the managed resource in a deleting state with a connectivity condition, rather than orphaning the external resource.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
backend, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.