akash-network / support

Akash Support and Issue Tracking
Apache License 2.0
5 stars 4 forks source link

feat: implement deploy operator #161

Open troian opened 9 months ago

troian commented 9 months ago

Rn manifest processing and deploy phases are tied together, which was a good solution at the time, now however it is causing quite a pain:

The problem

  1. whenever processing manifest and deploying workloads fails for whatever reason, the provider tears deployment down including manifest. This is especially painful during the upgrade phase when a new version of the manifest is introduced.
  2. The manifest controller does not support multiple manifest versions, which again creates huge pain during the upgrade process.
  3. Hostnames and IPs processing are currently done in the deployment manager. Both features are cluster-specific, and yet again migration process with the current implementation is quite challenging.

The solution

Actual deployment of the Kubernetes objects must be done by the independent operator. It watches create/update/delete events of the manifest and makes changes to deployment based only on those events. The operator must support multiple manifest versions and update to the latest possible whenever configuration allows it. Failures during deployment must not affect the manifest.

The Kubernetes Client only processes manifests (derives hostnames and IPs if any) and stores/deletes them as CRD objects. Kubernetes Client must ensure the correctness of CRD to specification. The Client must support multiple manifest versions.

brewsterdrinkwater commented 9 months ago

December 19th, 2023:

brewsterdrinkwater commented 8 months ago

January 9th, 2024:

brewsterdrinkwater commented 6 months ago

April 2nd: