Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenGitOps

opengitops.dev

Post reply on HN
Print view View original

21–30 of 51 posts

Re: OpenGitOps

#21

Post by FridgeSeal »

XorNot wrote: post #9
gpi wrote: post #3

ArgoCD is the defacto gitops standard now and has the lions share of gitops deployments.

Which is funny because ArgoCD is...miserable. Like it just doesn't do anything other then clone a branch and run a blind kubectl apply - it'll happily wedge your cluster into a state requiring manual intervention.

Yeah I have to use it at work currently, and it’s not great. Personally I find FluxCD so much better.

Less setup, faster, and in my experience so far, no “wedging the cluster in a bad state” which I’ve defs observed with Argo.

Re: OpenGitOps

#23

Post by bo0tzz »

gitttnwmrlg wrote: post #22

What’s the (practical) difference between section 3 and 4? Please explain.

The system should undo state drift even if a run hasn't been prompted by changes to the upstream definitions in the repository

Re: OpenGitOps

#24

Post by gitttnwmrlg »

neurodyne wrote: post #15
locknitpicker wrote: post #13

Earlier quoted context omitted.

> ArgoCD is the defacto gitops standard now and has the lions share of gitops deployments. That only covers pull-based GitOps. Push-based GitOps doesn't require Kubernetes, let alone magical Kubernetes operators, only plain old CICD pipelines.

I often hear folks use terminology like “push GitOps”. But as far as I understand things, it’s only GitOps if you’re following the four principles described in TFA. Otherwise it’s just sparkling pipelines.

The problem with automatically applying whatever crap that is stored in git, means that you cannot reverse anything without a long heavyweight process, clone code, make a branch, create a pr, approve a pr, merge to master/main.

That can take hours, and that’s not acceptable when PROD is burning.

That’s why most places don’t dare syncing to prod automatically.

Re: OpenGitOps

#25

Post by acedTrex »

locknitpicker wrote: post #14
gpi wrote: post #8

Earlier quoted context omitted.

The whole premise of opengitops is heavily reliant on kubernetes.

> The whole premise of opengitops is heavily reliant on kubernetes. There's indeed a fair degree of short-sightedness in some GitOps proponents, who conflate their own personal implementation with the one true GitOps. Back in the real world, the bulk of cloud infrastructure covers resources that go well beyond applying changes to pre-baked Kubernetes cluster. Any service running on the likes of AWS/Google Cloud/Azure…

> and Kubernetes operators neither cover those nor are a reasonable approach to the problem domain.

I mean Crossplane is a pretty popular k8s operator that does exactly that, create cloud infrastructure from K8s objects.

Re: OpenGitOps

#26

Post by mroche »

dijit wrote: post #18
jpillora wrote: post #17

The problem with git ops only manifests after it’s become a standard within an org: With 1 git ops pipeline, it’s fine, it’s the human merge gate, it’s doing its job protecting downstream With multiple git ops pipelines however, they start to get in the way of progress - especially when they need to be joined in series The better approach is to build API-first then optionally, add an API client into your git pipeline

> With multiple git ops pipelines however, they start to get in the way of progress - especially when they need to be joined in series Definitely, that's why systems like Zuul exist. They're esoteric and require a lot of engineering discipline in patience- but in my experience most people who reach for gitops aren't doing it for a sense of "everything as code" (for the audibility and theoretical reproducibility of it…

Would you mind elaborating on this more, describing the differences and how tools like Zuul introduce degrees of friction that result in smooth operation and pipelines?

I know my phrasing may come off wrong, I apologize for that. But I'm asking genuinely; I've only ever seen Zuul in the wild in the Red Hat and OpenStack ecosystems.

Re: OpenGitOps

#27

Post by Carrett »

Does it really make sense to use Kubernetes in 2026? Especially in the cloud? I think it’s just adding unnecessary layers, increasing operational debt, and complicating the developer experience.

Re: OpenGitOps

#28

Post by locknitpicker »

gitttnwmrlg wrote: post #24
neurodyne wrote: post #15

Earlier quoted context omitted.

I often hear folks use terminology like “push GitOps”. But as far as I understand things, it’s only GitOps if you’re following the four principles described in TFA. Otherwise it’s just sparkling pipelines.

The problem with automatically applying whatever crap that is stored in git, means that you cannot reverse anything without a long heavyweight process, clone code, make a branch, create a pr, approve a pr, merge to master/main. That can take hours, and that’s not acceptable when PROD is burning. That’s why most places don’t dare syncing to prod automatically.

> The problem with automatically applying whatever crap that is stored in git, means that you cannot reverse anything without a long heavyweight process, clone code, make a branch, create a pr, approve a pr, merge to master/main.

Nonsense. Your process is only as complex as you want it to be. Virtually all git providers allow you to revert commits from their GUI, and you can configure pipelines to allow specific operations to not require PRs.

As a reference, in push-based GitOps it's pretty mundane to configure your pipelines to automatically commit to other git repos without requiring PRs. This is the most basic aspect of this whole approach. I mean, think about it: if your goal is to automate a process then why would you go through great lengths to prevent yourself from automating it?

Re: OpenGitOps

#29

Post by locknitpicker »

neurodyne wrote: post #15
locknitpicker wrote: post #13

Earlier quoted context omitted.

> ArgoCD is the defacto gitops standard now and has the lions share of gitops deployments. That only covers pull-based GitOps. Push-based GitOps doesn't require Kubernetes, let alone magical Kubernetes operators, only plain old CICD pipelines.

I often hear folks use terminology like “push GitOps”. But as far as I understand things, it’s only GitOps if you’re following the four principles described in TFA. Otherwise it’s just sparkling pipelines.

> I often hear folks use terminology like “push GitOps”. But as far as I understand things, it’s only GitOps if you’re following the four principles described in TFA.

Not quite. You hear gatekeeping from some ill-advised people who either are deeply invested in pushing specific tools or a type of approach, or fool themselves into believing they know the one true way.

Meanwhile, people who do push-based GitOps just get stuff done by configuring the pipelines to do very simple and straigh-forward stuff: package and deliver deployment units, update references to which deployment units must be deployed, and actually deploy them.

The ugly truth is that push-based GitOps is terribly simple to pull off, and doesn't require any fancy tools or software or kubernetes operators. Configuration drift and automatic reconciliation, supposedly the biggest selling point of pull-based gitops, is a non-issue because deployment pipelines are idempotent. You can even run them as cron jobs, if you'd like to. But maintaining trivial, single-stage pipelines does not make a impressive CV.

> Otherwise it’s just sparkling pipelines.

Yeah, simple systems. God forbid something is reliable, easy to maintain, robust, and straight-forward. We need full blown kubernetes operators running on timers instead, isn't it? Like digging moats around their job stability. It's madness.

Re: OpenGitOps

#30

Post by dijit »

mroche wrote: post #26
dijit wrote: post #18

Earlier quoted context omitted.

> With multiple git ops pipelines however, they start to get in the way of progress - especially when they need to be joined in series Definitely, that's why systems like Zuul exist. They're esoteric and require a lot of engineering discipline in patience- but in my experience most people who reach for gitops aren't doing it for a sense of "everything as code" (for the audibility and theoretical reproducibility of it…

Would you mind elaborating on this more, describing the differences and how tools like Zuul introduce degrees of friction that result in smooth operation and pipelines? I know my phrasing may come off wrong, I apologize for that. But I'm asking genuinely; I've only ever seen Zuul in the wild in the Red Hat and OpenStack ecosystems.

Right, so Zuul is properly interesting if you're dealing with multi-repo setups and want to test changes across them before they merge; that's the key bit that something like GitLab CI doesn't really do.

The main thing with Zuul is speculative execution. Say you've got a queue of patches waiting to merge across different repos. Zuul will optimistically test each patch as if all the patches ahead of it in the queue have already merged.

So if you've got patches A, B, and C queued up, Zuul tests:

* A on its own

* B with A already applied

* C with both A and B applied

If something fails, Zuul rewinds and retests without the failing patch. This means you're not waiting for A to fully merge before you can even start testing B - massive time saver when you've got lots of changes flowing through. With GitLab CI, you're basically testing each MR in isolation against the current state of the target branch. If you've got interdependent changes across repos, you end up with this annoying pattern:

* Merge change in repo A

* Wait for it to land

* Now test change in repo B that depends on it

* Merge that

* Now test change in repo C...

It's serial and slow, and you find out about problems late. If change C reveals an issue with change A, you've already merged A ages ago.

Zuul also has this concept of cross-repo dependencies built in. You can explicitly say "this patch in repo A depends on that patch in repo B" and Zuul will test them together. GitLab CI can sort of hack this together with trigger pipelines and artifacts, but it's not the same thing... you're still not getting that speculative testing across the dependency tree.

The trade-off is that Zuul is significantly more complex to set up and run. It's designed for the OpenStack-style workflow where you've got dozens of repos and hundreds of patches in flight. For a single repo or even a handful of loosely-coupled repos, GitLab CI (and it's ilk) is probably fine and much simpler. But once you hit that multi-repo, high-velocity scenario, Zuul starts to make proper sense. Yet nobodies using it except hardcore foundational infrastructure providers.

Post reply on HN