sozu icon indicating copy to clipboard operation
sozu copied to clipboard

Focus the state on clusters, prevent orphan frontends and backends

Open Keksoj opened this issue 1 year ago • 1 comments

The good practice, when creating a new cluster, is documented, but not enforced:

  1. create a listener (on address 0.0.0.0:8080 for instance)
  2. create a cluster with an id and load balancing rules (my-todo-application)
  3. create a frontend that contains both:
    • the listener address 0.0.0.0:8080
    • the cluster id my-todo-application
  4. create backends with both:
    • the cluster id my-todo-application
    • the address of the actual application in the infrastructure (154.23.12.98:80 for instance)
  5. deleting a listener, a cluster, a frontend or a backend is done individually, with one request for each operation.

The only rule enforced by Sōzu, as of 2023-09-22, is that it is impossible to create a frontend if the address has no listener. In other words, you can't perform step 3 if step 1 is not executed.

We have realized, however, that these wrong behaviours are allowed by Sōzu:

  • step 3 without step 2: it is possible to create an HTTP|HTTPS|TCP frontend that is not linked to a cluster (cluster_id: None), in other words, create an orphan frontend
  • step 4 without step 2: it is possible to create a backend with a wrong cluster_id, in other words: create an orphan backend.
  • incomplete step 5: it is possible to delete a cluster without deleting its associated backends and frontends, in other terms, create orphan frontends and backends

This behaviour should be prevented by failsafe mechanisms:

  • check that step 2 has been done by thoroughly checking that the linked cluster exists
  • perform step 5 in one go, by deleting a cluster together with its associated frontends and backends

Keksoj avatar Sep 22 '23 13:09 Keksoj