[Tracking] Automatic Application Discovery

[thisthat]

Goal

Support KLT adoption by automatically discover the workloads that belongs to a specific application without requiring a KeptnApp.

Problem

In the case of a multi-service application, users need to create a KeptnApp CRD besided annotate their manifests with recommended labels or Keptn-specific labels.
If the KeptnApp CRD is not present, the pods are stuck waiting to be bound to a node.
This should not be the case and the KLT should be able to automatically infer the KeptnApp based on the labels.

Technical Details

The KLT should be able to work also without a KeptnApp CRD.
In this mode, the KLT has some limitations:

• no App pre-flight checks
• no App post-flight checks
• no prevention of a wrong workload version being deployed

The inferred KeptnApp should then be stored in ETCD for future usages, e.g., rollback.

DoD

• KLT runs in a passive mode and does not block any deployment
• Observability is working out-of-the-box

Tasks

Preview Give feedback

1. Research: Support automatic application discovery #517
   enhancement +1
   
2. Bootstrap KeptnAppCreationRequest #612
   enhancement +1
   
3. Implement logic for KeptnAppCreationRequest controller #613
   enhancement +1
   
4. Adapt mutating webhook to create KeptnAppCreationRequest resources #623
   enhancement +1
   
5. Create documentation and examples for KeptnAppCreationRequest #629
   documentation enhancement +2
   
6. Adapt behaviour of KeptnAppCreationRequest controller during corner cases processing #728
   enhancement +1
   

[odubajDT]

open questions:

• what if another deployment/pod/RS/DS/SS with the same KeptnApp name is deployed during the deployment of the application, should it be considered?
• restartability of an application, should we allow the users to somehow restart the application? for example by adding/removing/updating some of the deployment/pod/RS/DS/SS with the referenced app?