I believe GitOps friendly promotion tool like Kargo is really needed. I think in general CI/CD tools have a hard time enabling all use cases and workflows because every company has it’s own process or conventions. So I don’t blame Kargo for being opinionated because it’s probably unattainable to fit all workflows. They also said in V1 announcement that they intend to support Terraform as well…which I don’t know if that’s a marketing hype or a real intention 😅
@ nope, I’ve just replaced deploy steps with Kargo, now with promotion directives Kargo is now more flexible, I think they will more flexibility with time. Sharding is working fine as well. But I haven’t used analytics templates for now. I had to separate monocharts and split it to bunch of separate projects it Kargo
Thanks for finally making the video! I completely agree with you about the documentation-it’s absolutely terrible. Period. I’ve given two talks about Kargo: one before version 1.0 and one after. In both cases, it took a lot of effort to get my use case working (Pure GitOps, no branches, and updating the dependency of a Helm umbrella chart). That said, as you pointed out, Kargo has the potential to become the tool for all things promotion. Whether it’s with a polished UI (hello, Argo CD!) and manual gates (enterprise-ready!) or fully progressive workflows, it’s on the right path. I also think it won’t be long before there’s an option to create custom workflow steps, which should address some of its current shortcomings in time.
Thanks for making this! Simply put, Kargo is a controller for some new resources incl. "Freight" plus a cool UI for observing and approving promotions? I wonder if the k8s events from these resources are sufficient for integrating other tools. Philosophically, I'd like to see the rendered manifests treated as "artifacts" that are published to OCI, but I have heard some counter arguments.
It's a nice tool for devs, and could be great for shift-left. Unfortunately it's unusable for a lot of people due to the fact that it doesn't support things like Datadog version tags in annotations, so basically updating anything outside of the basics like image tag when using kustomize wasn't possible in our testing. Still watching it though.
if you render the YAML for all of your stages from your kustomize/helm via CI (adding whatever Datadog annotations you need - or the labels Viktor was thinking of in the video) like this video: th-cam.com/video/FWE2247octI/w-d-xo.html you can then use kargo to promote/rollback by just telling ArgoCD to point at the git SHA of the properly generated YAML with all the annotations/labels you require - this also lets you avoid having lots of branches; just 1 branch for your GitOps releases with a folder per stage/cluster
For some time (even before adopting GitOps), I used docker tags as promotion flag in pipeline scripts (e.g. "docker pull app:XXXX && docker tag app:XXXX app:prod-XXXX && docker push app:prod-XXXX") which can be executed automatically or manually after testing. After switching to GitOps, I considered using Flux Image Automation to automatically deploy these tags in corresponding environments. If it were done that way, it would have become my own analogue of kargo. But it wasn't, because of the same synchronization problem: pipeline has no way to know the moment when promoted version is deployed in specific environment. So it was finally become classic and obvious "yq -i && git commit && git push && flux reconcile --with-source". P.S. Interesting. Just checked docs on Flux Notification Controller and found that it supports emitting events to NATS. Maybe, asynchronous pipelines using image repo as outbound event bus and NATS as an inbound one is already possible today, but it requires some testing.
That's certainly an option but argo events themselves are problematic and probably the Argo project that received the least love. On top of that, while that is possible it becomes unnecessarily complex. I am doubting the usage of kargo over simply updating yaml in workflows. If events need to be added my doubts only increase.
What do you think of Kargo? Do we need such a tool (promotions) and, if we do, do you think Kargo is the one?
I believe GitOps friendly promotion tool like Kargo is really needed. I think in general CI/CD tools have a hard time enabling all use cases and workflows because every company has it’s own process or conventions. So I don’t blame Kargo for being opinionated because it’s probably unattainable to fit all workflows. They also said in V1 announcement that they intend to support Terraform as well…which I don’t know if that’s a marketing hype or a real intention 😅
Im using kargo on 2 my projects, and generaIly I like it
@@koushyk did you had adjust your existing setup/workflow/release process to fit in Kargo?
@ nope, I’ve just replaced deploy steps with Kargo, now with promotion directives Kargo is now more flexible, I think they will more flexibility with time. Sharding is working fine as well. But I haven’t used analytics templates for now. I had to separate monocharts and split it to bunch of separate projects it Kargo
Thanks for finally making the video! I completely agree with you about the documentation-it’s absolutely terrible. Period. I’ve given two talks about Kargo: one before version 1.0 and one after. In both cases, it took a lot of effort to get my use case working (Pure GitOps, no branches, and updating the dependency of a Helm umbrella chart).
That said, as you pointed out, Kargo has the potential to become the tool for all things promotion. Whether it’s with a polished UI (hello, Argo CD!) and manual gates (enterprise-ready!) or fully progressive workflows, it’s on the right path. I also think it won’t be long before there’s an option to create custom workflow steps, which should address some of its current shortcomings in time.
Thanks for making this! Simply put, Kargo is a controller for some new resources incl. "Freight" plus a cool UI for observing and approving promotions? I wonder if the k8s events from these resources are sufficient for integrating other tools. Philosophically, I'd like to see the rendered manifests treated as "artifacts" that are published to OCI, but I have heard some counter arguments.
It's a nice tool for devs, and could be great for shift-left. Unfortunately it's unusable for a lot of people due to the fact that it doesn't support things like Datadog version tags in annotations, so basically updating anything outside of the basics like image tag when using kustomize wasn't possible in our testing. Still watching it though.
if you render the YAML for all of your stages from your kustomize/helm via CI (adding whatever Datadog annotations you need - or the labels Viktor was thinking of in the video) like this video: th-cam.com/video/FWE2247octI/w-d-xo.html you can then use kargo to promote/rollback by just telling ArgoCD to point at the git SHA of the properly generated YAML with all the annotations/labels you require - this also lets you avoid having lots of branches; just 1 branch for your GitOps releases with a folder per stage/cluster
true
You can use analysisrun to run arbitrary k8s jobs after promotion, incl. tests...
I came here to say this. Looks like Viktor made some assumptions as well! 😅
Amazing! tx for this video Viktor!
For some time (even before adopting GitOps), I used docker tags as promotion flag in pipeline scripts (e.g. "docker pull app:XXXX && docker tag app:XXXX app:prod-XXXX && docker push app:prod-XXXX") which can be executed automatically or manually after testing.
After switching to GitOps, I considered using Flux Image Automation to automatically deploy these tags in corresponding environments. If it were done that way, it would have become my own analogue of kargo. But it wasn't, because of the same synchronization problem: pipeline has no way to know the moment when promoted version is deployed in specific environment. So it was finally become classic and obvious "yq -i && git commit && git push && flux reconcile --with-source".
P.S. Interesting. Just checked docs on Flux Notification Controller and found that it supports emitting events to NATS. Maybe, asynchronous pipelines using image repo as outbound event bus and NATS as an inbound one is already possible today, but it requires some testing.
Thank you, very informative.
"I assume you know Argo, if not:
1. Be ashamed...
2. Once the shame wears off: learn Argo"
😂😂😂 Im rolling
Have you open GitHub issue about the Event or integrations to workflows?
I did not open an issue but I did discuss it with people from the project.
Can you not use Argo Events to trigger test automation based on the deployment events from Kargo?
That's certainly an option but argo events themselves are problematic and probably the Argo project that received the least love. On top of that, while that is possible it becomes unnecessarily complex. I am doubting the usage of kargo over simply updating yaml in workflows. If events need to be added my doubts only increase.