You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adapt webhook to generate KeptnAppCreationRequest resources to support of automatic discovery of the application, where a multi-service/single-service application will not require a user-defined KeptnApp resource.
Technical Details
Changes of mutating webhook
According to the research and a PoC we came to a conclusion that the KeptnAppCreationRequest resource should be created by mutating webhook. In the same time creation of the KeptnApp resource (in the current state only for single-service applications) should not be part of mutating webhook and will be part of the KeptnAppCreationRequest controller. We won't need two different implementations paths to distinguish anymore between a single-service of multi-service applications, although there will be a small difference.
Workflow:
Webhook receives a Pod and checks the annotations:
if the Pod has application annotation, it is part of multi-service application (check like this)
if it does not have them, we are dealing with a single-service application
In the second step webhook will try to retrieve KeptnAppCreationRequest resource for the application -> the name of the KeptnAppCreationRequest is the same as the name of the application (and the name of the future KeptnApp)
if it finds it, it does nothing
if it does not find it, webhook will create KeptnAppCreationRequest resource. Its name will be the same as the name off the application. Additionaly, the KeptnAppCreationRequest will have the following labels:
keptn.sh/app-type: (single-service|multi-service) -> this is important for the KeptnAppCreationRequest controller to know whether he should wait for the rest of workloads to be applied to the cluster, or can directly move on to creation of KeptnApp
Acceptance Criteria
Mutating webhook does not create KeptnApp resources
odubajDT
changed the title
Adapt mutating webhook to create KeptnAppCreationRequest resources
Adapt mutating webhook to create KeptnAppCreationRequest resources
Jan 13, 2023
Part of #514
Pre-requisites:
Goal
Adapt webhook to generate
KeptnAppCreationRequest
resources to support of automatic discovery of the application, where a multi-service/single-service application will not require a user-definedKeptnApp
resource.Technical Details
Changes of mutating webhook
According to the research and a PoC we came to a conclusion that the
KeptnAppCreationRequest
resource should be created by mutating webhook. In the same time creation of theKeptnApp
resource (in the current state only for single-service applications) should not be part of mutating webhook and will be part of theKeptnAppCreationRequest
controller. We won't need two different implementations paths to distinguish anymore between a single-service of multi-service applications, although there will be a small difference.Workflow:
Webhook receives a Pod and checks the annotations:
In the second step webhook will try to retrieve
KeptnAppCreationRequest
resource for the application -> the name of theKeptnAppCreationRequest
is the same as the name of the application (and the name of the futureKeptnApp
)KeptnAppCreationRequest
resource. Its name will be the same as the name off the application. Additionaly, theKeptnAppCreationRequest
will have the following labels:keptn.sh/app-type
: (single-service|multi-service) -> this is important for theKeptnAppCreationRequest
controller to know whether he should wait for the rest of workloads to be applied to the cluster, or can directly move on to creation ofKeptnApp
Acceptance Criteria
KeptnApp
resourcesKeptnAppCreationRequest
resourcesDoD
Note
PoC of implementation available here: #559
The text was updated successfully, but these errors were encountered: