Questions around lifecycle-controller

[vadasambar]

Sorry for the barrage of questions. I think some of my questions might get answered once I go through the code but I am noting them down here as well (so that I can write the answers myself once I get more clarity)
1.

The goal of this prototype is to introduce a more “cloud-native” approach for pre- and post-deployment, as well as the concept of application health checks.

Are we trying to replicate something similar to what ArgoCD pre and post deployment hooks do (since we can't really use ArgoCD here because we use helm-service to deploy our helm charts)
2.

Application and Service Controllers watchfor the workload resources to finish and then generate a Post-Deployment Event.

Does workload resources to finish here mean the deployment moves from one Keptn stage to another (hardening -> production for example).
3. Is the Application resource there for telling the application controller what pre-deploy or post-deploy Job should be run for a specific service?
4. Is the Service resource there for telling the service controller about user manifests i.e., is the service controller applying the manifests here? What role does service controller play here?
5.

After the Post-Deployment checks, SLOs can be validated using an interface for retrieving SLI data from a provider, e.g, Prometheus. Finally, Keptn Lifecycle Controller exposes Metrics and Traces of the whole Deployment cycle with OpenTelemetry.

Do we want to run some kind of tests in the post-deployment here and then use an SLO and SLI for that (similar to what we do with lighthouse-service + sli providers in Keptn right now) here? What roles do the SLI and SLO controller play here?

[vadasambar]

📝

1. Seems to be answered in a demo that @thschue published recently. https://www.youtube.com/watch?v=xVzaM5m6ohk It seems like we are using the lifecycle-controller for pre and post deployment hooks (like ArgoCD)
2. Application seems to be a resource (from the youtube video linked above) to group different resources (K8s Deployments, Daemonsets, Statefulsets etc.,) and can have Application level pre and post deployment hooks (as opposed to resource e.g., K8s Deployment level pre and post-deploy hook).

[thschue]

Hello and thank you for your feedback!

Please consider the lifecycle controller as a new approach in parallel to the current keptn. It has no relation to keptn-services and is not aiming to deploy applications by itself (but will be able to be orchestrated by tools like ArgoCD and flux).

1. The approach is very similar to Helm or Argo Hooks but independent of the deployment tooling and will also include the possibility of running functions and possibly triggering cloud events
2. The Lifecycle Controller by itself will do no promotion (but it can be scripted)
3. The App Resource will specify which Workloads in which version belong to an application (to set the App Boundaries) and define which tasks will be triggered on pre- and post-deployment. At the moment, the tasks for a specific Workload/Service will be set via annotations
4. The Workload(Service) resource will be automatically created from the annotations. This resource describes the current desired state of the service, and the current state per Version (pre-/post-deployment checks, service health, ...) is tracked and managed in Workload Instance resources
5. The SLI and SLO Controllers are used to evaluate the Application's Health. Tests could and should be part of post-deployment.

[vadasambar]

Thank you for answering my questions. It seems like Service is used to for more granular checks as opposed to Application which will have checks that will apply for all the manifests.

[thisthat]

Exactly. You can think of your application as a composition of several workloads (we switched from service to workload as a naming).
For example, as an application check, you could verify that there are no current open problems in your infrastructure. If everything is fine, you could proceed and run more fine-grained checks specific to each workload. For example, the external DB used by one of your microservice is up and running.

[vadasambar]

https://docs.google.com/presentation/d/1satTEbjIoCZXLyx40i-IdV3hWd8ctnMz/edit#slide=id.p14 adds further context to the "why" behind lifecycle-controller