What was the motivation behind creating lifecycle-controller?

[vadasambar]

It seems like we wanted to build a completely independent implementation based on our requirements as a prototype and eventually fit in with ArgoCD which makes sense to me.

Here are the benefits I see in our controller (which I think ArgoCD doesn't offer):

1. Workload is not scheduled until the check passes (I don't think ArgoCD offers this)
2. Our controller offers per workload (read: Pod) pre and post deployment check whereas ArgoCD seems to offer Application level checks

Here are the similarities I see with ArgoCD:

1. ArgoCD offers hooks for pre and post-deployments
2. You can run an Argo Workflow which offers the feature of using one Workflow template in another (just like our KeptnTaskDefinition CR)
3. ArgoCD offers the Application abstraction
4. ArgoCD offers application level health checks

[thisthat]

Hey @vadasambar 👋
I'll try to comment on your point here following your structure.
Benefits:

1. 👍 exactly.
2. There is also work to offer application level checks with feat(operator): Add KeptnApplication controller #137
   Similarities:
3. Yes, the concept is similar but you are bound to the tool. The lifecycle controller aims at being tool independent. You could use Flux, Argo, Helm, Jenkins, .. you name it. You should be able to do these things independently from the tool you are using for carrying out your deployment
4. 👍
5. 👍
6. Here we are different. Health checks in Argo are defined as "all the resources of you Application meet their K8s definitions". This does not look into the Application itself for checking its healthiness. Think about your Application is made by a single pod serving a website which is running and health/readiness probes are ok. However, it's response time is 10s. You can argue that this would not be an healthy state for your application. Hence, the Lifecycle Controller wants to establish the concept of Health Checks via SLO/SLI definition.

[vadasambar]

Thank you for answering my questions 🙏