chologrande

why yaml plus real code? why not just real code? does yaml ever actually provide benefits in testing like this?

I can simply run `helm install cert-manager` or `kubectl operator install cert-manager -n cert-manager --channel stable --approval Automatic --create-operator-group ` - both have dependency resolution.

Not trying to be negative here, trying to understand if there is value or functionality missing from established solutions, because it's not obvious to me.

How is this any smaller than OLM or the Operator pattern? Having trouble seeing the differentiator other than "it's different"

I work at a recently IPO'd tech company. Oxide was a strong consideration for us when evaluating on prem. The pitch lands among folks who still think "on prem.... ew".

Looks like a cloud like experience on your own hardware.

If only it were as cheap as dell...

> Had to do a lot of work to get node utilization ... higher than 50%

How is this the schedulers fault? Is this not just your resource requests being wildly off? Mapping directly to a "fly machine" just means your "fly machine" utilization will be low

oh that's nice I didn't know that! Still a stickler on yaml for code though

The blog perfectly sums up the feelings of anyone who has worked deep in jenkins. It works, but goddamn it's hard not to hate.

Dagger is the answer to jenkins woes. It's saved my sanity and made CI development tolerable again.

* Real language support. No groovy, no yaml.

* Debugging available in your native IDE tools.

* Clear docs in any language of your choice.

* Reproducible builds you can run locally. Just need docker.

This all comes with the bonus that it can actually just consume GHA yaml with some of the tooling folks have made.

How is Gitlab CI materially different from the jenkins model?

I find that the only difference is that it's YAML - so even harder to debug, and maintains the same model where you must re run an entire pipeline every commit to test functionality.

wow I can't facepalm any harder, I hadn't seen the architecture docs etc in the top level repo... and they're at the top level.

I'm just skimming, but it looks like the docs are fantastic. I've spent some time with terraform internals, and this seems like a significant improvement for a dev looking to work with this codebase. Gives a great overview to get started. well done!

Hate to only shill hashi stack but packer if you must. All you need is a container runtime and linux kernel. After that you shouldn't have to think about the core node.

If you're _really_ bare metal - build the base image, boot pxe and run apt update - not much more complicated than that.

Ansible is great, but (imo) aged. Sure it's good for dealing with legacy hardware that cannot support terraform like state, but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.

Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.

100% - having to submit code server side to just get compilation results is the worst development loop I've ever experienced.

Sure - but where's the revenue come from?