Closed braghettos closed 1 month 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.
@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:
@krancour thanks for your response! I was talking about totally different apps but both the scenarios are equally important.
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.
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?
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.
I will try to put together a demo to showcase how to address both scenarios!
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.
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?