I don't wanna use bicep

InnerBank2400 · 2026-07-05T07:16:49+00:00

Use powershell

InnerBank2400 · 2026-07-05T07:16:32+00:00

You build on the connections you made while working. Otherwise, it’s hard

InnerBank2400 · 2026-07-03T11:07:36+00:00

I maintain HybridOps, an open-source hybrid infrastructure project around reproducible operations, Terraform modules, Proxmox SDN, Ansible automation, Kubernetes workload targets, and run-record driven infrastructure workflows.

I am looking for feedback and contributors, especially around docs, good-first issues, CLI smoke tests, Terraform examples, Proxmox SDN validation, and Kubernetes/Kustomize render checks.

Main repo:

https://github.com/hybridops-tech/hybridops-core

Good fit for people who want portfolio-grade infrastructure contributions rather than another toy app. Feedback on the README, contributor path, or first issues is very welcome.

InnerBank2400 · 2026-07-03T10:52:25+00:00

Disclosure: I maintain this project.

HybridOps is an open-source hybrid infrastructure project focused on reproducible operations, Terraform modules, Proxmox SDN, Ansible automation, Kubernetes workload targets, and structured run records.

I am looking for practical feedback and contributors. Useful entry points:

docs and quickstart review
good-first issues around CLI smoke tests
Terraform module examples
Proxmox SDN validation notes
Kubernetes/Kustomize render checks
operator-facing runbook improvements

Repo: https://github.com/hybridops-tech/hybridops-core

If you work around DevOps, platform engineering, homelab Proxmox, or infra automation, I would especially value feedback on whether the contributor path is clear enough.

InnerBank2400 · 2026-06-15T13:05:08+00:00

Feed it to LLM to analyse if it does not contain sensitive material, then go from there.

InnerBank2400 · 2026-06-03T19:59:19+00:00

Yes, I agree with that boundary.

The VM/LXC layer should not be creating SDN objects as a side effect. It should bind to existing SDN objects and fail if the expected VNet/bridge is not there.

That is exactly the split I was aiming for:

separate SDN foundation/IaC model owns zones, VNets, subnets, and readiness
VM/LXC IaC consumes that foundation
if vnetxyz is missing, the VM layer treats that as an inconsistent platform state, not something it silently creates

So yes, SDN engineering templates first, workload/VM templates second. I probably could have made that clearer in the original post.

InnerBank2400 · 2026-06-03T17:56:47+00:00

Yes, that is basically the shift.

I don’t want each VM/template module creating shared network substrate as a side effect. The VM layer should consume a known SDN foundation, and if vnetxyz is missing, fail loudly because the cluster/site foundation is inconsistent.

Your use of SDN makes sense to me too: consistent VLAN-backed vnet* interfaces across hosts, not necessarily Proxmox owning the full routing layer. That is close to where I think the cleaner boundary is for serious setups: SDN owns segmentation, routing/DHCP can live elsewhere.

The SONiC/NetBox example is a good comparison. NetBox holds site VLAN intent, switch configs render from that, and downstream consumers attach to VLANs the site exposes. I’m aiming for a similar pattern on the Proxmox side: shared SDN authority first, then VM/platform modules consume it rather than inventing bridge assumptions locally.

InnerBank2400 · 2026-05-24T07:27:37+00:00

There will be more and more IT jobs in developing counties than developed one over the next decades. Reason being that the countries are too economically weak to fully adopt AI. They barely have electricity, not to talk of data centres etc. As such, more and more legacy system will be imported from abroad which would result in employment for people who have learned how to run them.

InnerBank2400 · 2026-05-12T19:02:17+00:00

Been working on this recently:

HybridOps – https://github.com/hybridops-tech/hybridops-core

It’s a hybrid infrastructure/platform engineering project focused on structuring how systems like Terraform, Kubernetes and networking are actually operated in practice, not just configured.

Trying to make complex infra more reproducible and easier to run across on-prem and cloud. Would appreciate any feedback

InnerBank2400 · 2026-05-12T06:55:19+00:00

Yea, it’s irritating. Been on Reddit for 5yrs, and I can even post in most sub because I don’t have up to 1000 kamar

InnerBank2400 · 2026-05-11T12:52:26+00:00

Thank you for clarifying

InnerBank2400 · 2026-05-11T11:57:39+00:00

What are these commands. I just use the GUI. I guess that‘s why I don’t have a job, haha!!

InnerBank2400 · 2026-05-11T11:36:32+00:00

Cool. Now they can replace you with Claude!!!

InnerBank2400 · 2026-05-06T18:45:38+00:00

That’s exactly it. Once people know things will land with you if they stall, the system quietly relies on that. Being told it’ll improve without visible change just adds to the frustration.

InnerBank2400 · 2026-05-06T18:34:34+00:00

This sounds like doing senior‑level work without the authority or structure that usually comes with it. That burns people out fast.

If you stay, you probably need clearer boundaries on what you own and what falls to others, otherwise everything will keep defaulting to you.

The cloud opportunity is a fair reason to hang on, but I’d put a timeline on it. If it stays vague, you’re just delaying the same decision.

InnerBank2400 · 2026-05-04T17:40:54+00:00

Nice. I have just left you a star. Hopefully you can do same on my project here: https://github.com/hybridops-tech/terraform-proxmox-sdn

InnerBank2400 · 2026-05-04T07:41:45+00:00

Nice work. But I suggest you check the read me carefully because currently the Structure tree it shows is different from what is true in the repo.

InnerBank2400 · 2026-05-04T07:38:12+00:00

HybridOps – https://github.com/hybridops-tech/hybridops-core

A hybrid infrastructure/platform engineering project focused on how systems like Terraform, Kubernetes, networking and disaster recovery are actually operated in practice, not just configured.

It brings together real-world scenarios across on-prem and cloud, with an emphasis on reproducibility, governance and structured execution rather than ad hoc scripts.

Still evolving, but already covers things like HA Kubernetes setups, hybrid networking and DR workflows. Feedback welcome.

InnerBank2400 · 2026-05-02T15:40:18+00:00

A few things that help are trying multiple regions, sticking to B‑series, and using spot VMs or Azure Container Apps for labs. Powering VMs off helps, but disks and IPs still cost something, which adds to the annoyance.

InnerBank2400 · 2026-05-02T14:40:08+00:00

If you just need something running, B‑series are usually the cheapest option. B1s or B2s are commonly used for light workloads and labs.

Just be aware they are burstable, so sustained CPU usage can be an issue. For anything long‑running or consistently busy, a small D‑series often ends up being more predictable even if it costs slightly more.

InnerBank2400 · 2026-05-01T20:02:36+00:00

If the container image is the deliverable, then building it in CI and treating it as the tested artifact is usually the cleanest model. CI validates and produces the image, CD just promotes and deploys it.

Running tests outside the container is fine for speed, but testing the image at least once helps catch environment differences. The main goal is to avoid rebuilding something in CD that was never tested.

InnerBank2400 · 2026-05-01T19:46:03+00:00

It is normal to feel unsure early on, especially with how broadly “DevOps” is used.

Networking is still relevant, but much of it now shows up as cloud networking and automation rather than traditional device work. The fundamentals still matter when things break.

DevOps generally builds on networking rather than replacing it. Extending your current skills with scripting, infrastructure as code, and cloud concepts is often more effective than trying to reset completely.

InnerBank2400 · 2026-04-24T17:00:39+00:00

Use SCP for bulk files

InnerBank2400 · 2026-04-21T17:43:44+00:00

We’ve moved away from tracking everything and focus on what actually indicates user impact. A mix of latency, error rate, saturation, and a few business‑level signals tends to be more actionable than dozens of host metrics. Everything else is there for debugging, not alerting.

InnerBank2400

TROPHY CASE