akuity / kargo

Application lifecycle orchestration
https://kargo.akuity.io/
Apache License 2.0
1.55k stars 135 forks source link

Promotion dependency on another Promotion #581

Closed braghettos closed 1 month ago

braghettos commented 1 year ago

I'm comparing Kargo with the legacy version of Keptn (https://v1.keptn.sh/) and what I think it's missing in actual concepts of Kargo is a concept of dependencies between promotions, i.e. I want to release app 'A' only if the app 'B' is being correctly synced/deployed. Both in Kargo and Keptn there is the concept of Stage.

In Keptn this concept is a Sequence in a Stage made of Tasks (https://keptn.sh/docs/1.0.x/define/task-sequence/). There are Remediation strategies in case of a failed deployment (https://keptn.sh/docs/1.0.x/define/remediation-sequence/#example-remediation-configuration) or quality gates that are not successfully passed (https://keptn.sh/docs/1.0.x/define/quality-gates/).

I believe Kargo and Keptn overlap in many aspects but the advantage of Kargo is that it is Kubernetes-native. There's a new version of Keptn (which is the Keptn Lifecycle Toolkit) which is more focused on checks of the actual Deployment.

I have used Keptn v1 for a long time and I believe it would be interesting in Kargo to add a concept of dependencies between Promotions. What do you think?

krancour commented 1 year ago

@braghettos thanks for your interest in the project and for your question!

One thing we're trying not to do is build overlapping functionality with GitOps platforms, especially Argo CD.

I'd be curious as to whether the Argo CD syncwaves start to address what you're asking about to some extent.

Something else that may be helpful to know is that Kargo stages do not need to be 1:1 with apps. One stage can manage promotions to multiple apps... and if those apps are part of a syncwave... you might be all set.

Admittedly, I have not tried this -- we're still nailing down basic functionality -- but this is sort of how we have imagined something like what you have described working.

krancour commented 1 year ago

@braghettos I was thinking about this more and realized your question may have been simpler than I realized...

i.e. I want to release app 'A' only if the app 'B' is being correctly synced/deployed.

To get more clarity on your question, in this scenario, are A and B:

  1. Entirely different apps?
  2. different instances of the same app? e.g. "A" might be "dev" and "B" might be "uat"?
braghettos commented 1 year ago

@krancour thanks for your response! I was talking about totally different apps but both the scenarios are equally important.

krancour commented 1 year ago

I was talking about totally different apps but both the scenarios are equally important.

So for the first scenario (totally different apps) Argo CD sync waves are still the theoretical answer.

For the second scenario, that is actually the main challenge Kargo was built to address. Stages transitioning to a new state after an "upstream" stage has successfully made the same transition is basically Kargo's primary feature.

braghettos commented 1 year ago

ArgoCD Sync doesn't allow to declaratively define a dependency on another app. Maybe the best scenario is to mix Kargo with Keptn Lifecycle Toolkit?

krancour commented 1 year ago

ArgoCD Sync doesn't allow to declaratively define a dependency on another app.

I believe it's done by using App of Apps + sync waves together.

braghettos commented 1 year ago

I will try to put together a demo to showcase how to address both scenarios!

krancour commented 1 month ago

Tentatively closing this because the notion of dependencies between Promotions does not seem to fit with the direction Kargo has taken since this issue was first opened.