Apisix-dashboard: request help: Is it normal that upstreams used by a router can be deleted directly?

[EnableAsync]

Please answer these questions before submitting your issue.

• Why do you submit this issue?
• [x] Question or discussion
• [ ] Bug
• [ ] Requirements
• [ ] Feature or performance improvement
• [ ] Other

---

Question

• What do you want to know?
  I can directly delete the upstream used by route in dashboard.
  Is this expected behaviour?

[juzhiyuan]

No, and this would be fixed in 2.1

[membphis]

• I can directly delete the upstream used by route in dashboard.
  Is this expected behaviour?

Yes, even if the upstream object is used in the route, we are allowed to delete it.

if the user is using the dashboard, we can show a warning message for confirming.

[membphis]

@nic-chen @gxthrj Please confirm that what I said above is correct.

[nic-chen]

• I can directly delete the upstream used by route in dashboard.
  Is this expected behaviour?

Yes, even if the upstream object is used in the route, we are allowed to delete it.

if the user is using the dashboard, we can show a warning message for confirming.

Yes, we could allow the deletion, which is like what k8s does.

[juzhiyuan]

🤔 some error will appear IMO

[membphis]

some error will appear IMO

yes, we know. that is acceptable.

The consumer of the API may be third-party platforms.
We allow to create Route (with Upstream object bound) first, and then create Upstream object.
Reduce the complexity of third-party platforms.

[juzhiyuan]

• I can directly delete the upstream used by route in dashboard.
  Is this expected behaviour?

Yes, even if the upstream object is used in the route, we are allowed to delete it.
if the user is using the dashboard, we can show a warning message for confirming.

Yes, we could allow the deletion, which is like what k8s does.

ok then @EnableAsync what do you think?

[EnableAsync]

• I can directly delete the upstream used by route in dashboard.
  Is this expected behaviour?

Yes, even if the upstream object is used in the route, we are allowed to delete it.
if the user is using the dashboard, we can show a warning message for confirming.

Yes, we could allow the deletion, which is like what k8s does.

ok then @EnableAsync what do you think?

I found that k8s has a parameter called "propagationPolicy" to control whether dependencies are automatically deleted or not[1].
I think it is possible to add a parameter like this to control whether or not dependencies can be removed.

[1] https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#controlling-how-the-garbage-collector-deletes-dependents

[gxthrj]

Yes, I think upstream can be deleted directly, and 503 can be used when the route cannot find upstream.
In other systems, such as k8s, this way is more respected.

The propagationPolicy is for GC, the scenario is to delete the deployment, which needs to be cascaded to delete replicasets and pods. You should not refer to this feature, because deployment, replicaset, and pod are inherited, they are different from upstream and route binding.

In APISIX, the relationship between the route and upstream can refer to the service and pod in k8s. They are the selection relationship of the selector label. We can indeed delete all pods, but the service is not affected.