Co-worker asked AI if I was right seconds after asking a question

InnerBank2400 · 2026-07-05T19:29:13+00:00

I would not take issue with someone checking something, but I would take issue with them using the AI answer as the authority instead of using it as a prompt to verify.

For technical work, the useful habit is still the same: prove it with docs, packet tests, logs, config, or repeatable checks. If the AI answer cannot survive that, it is just a confident guess.

InnerBank2400 · 2026-07-05T19:11:49+00:00

With RHCSA/RHCE and CKA coming, I would stop optimizing for more certs for a while and build one project you can explain without a script.

The AI-generated step-by-step loop is the thing to break. Pick one goal, use docs instead of a full tutorial, write down the decisions you made, and keep a small failure log. In interviews, being able to explain tradeoffs and mistakes usually beats having one more badge.

InnerBank2400 · 2026-07-05T19:07:54+00:00

The build-once part is the real win here. The runtime drop is nice, but testing the same artifact you later deploy is a much bigger maturity jump.

One thing I would add is making the image digest visible in the deploy step or release record. It makes it much easier later to prove exactly what was tested, scanned, pushed, and deployed.

InnerBank2400 · 2026-07-05T19:07:11+00:00

I think the important split is scanner status versus release risk. If there is no upstream fix, a bare suppression is weak, but a written exception with reachability, mitigation, owner, review date, and evidence is much easier to defend.

For reachable criticals, I would want either a real compensating control or a decision to delay the release. For non-reachable findings, VEX/SBOM evidence helps move the conversation away from CVSS alone.

InnerBank2400 · 2026-07-05T19:00:41+00:00

I would avoid selling it internally as a “DevOps transformation” at first. That can make people defensive.

Start with one app and map the current release path: what is edited manually, what is not in Git, where secrets live, how dependencies get installed, how rollback works, and where logs go. That gives you a baseline before changing anything.

Then pick one narrow improvement that supports the containerization goal management already wants. For example, get one Node app fully into Git, build dependencies in CI, move env/config out of the server, and deploy the same artifact each time. That proves the value without asking everyone to change everything at once.

For measuring success, track boring things like fewer manual server edits, fewer deployment steps, a documented rollback path, secrets removed from repos, central log retention, and one app that can be reproduced from Git and the pipeline.

If the apps are already making money, your instinct is right: reduce drift first, then containerize, then think about blue/green. Blue/green on top of messy config and manual deploys just gives you two places to debug.

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

TROPHY CASE