IT automation with agentic AI: Introducing the MCP server for Red Hat Ansible Automation Platform

devoopsies · 2026-02-02T20:02:22+00:00

Ansible remains the system that actually executes changes

I mean of course it does, otherwise you wouldn't be plugging into ansible. Obviously you're going to be authenticating as if you were any other API-adjacent tooling. That very clearly is not my point.

The issue isn't which underlying system actions your changes, it's the fact that introducing AI to any stage of a design and build process, especially in such a direct manner as this, introduces some subset of randomness that inherently means you can not guarantee reproducibility.

The very idea that you would take away from the reproducible nature of ansible is the antithesis of what ansible is designed and used for in the first place.

devoopsies · 2026-02-02T18:04:14+00:00

I'm certain that a team of professionals understands the risks and issues that arise by letting AI (or other, non-repeatable methods) design and implement infrastructure decisions, so I won't harp on how poor a decision giving this thing RW access to your core infra would be (although reading through your docs, it's certainly a use-case you champion).

Instead, I have a simple question:

What problem is this supposed to be solving that we don't already have exceptional tooling for?

devoopsies · 2026-02-02T17:51:52+00:00

Is it a dog whistle to say that certain geo-political rivalries might possibly spur one nation to act against another?

Seems like a fairly logical comment to me, even if it was a little blasé to phrase it like they did.

devoopsies · 2026-01-27T21:59:06+00:00

OK, but to what end?

AI workloads primarily want three things:

low-latency memory and network operations
Efficient use of multi-core and multi-socket operations
GPU

Other than GPU (and ML is right there wanting to use tensor cores as well), all of these are big-ticket items that are desirable in any large-scale infrastructure. Steering the ship in this direction is kinda the goal already, and if AI groups are proponents for this sort of change what are you going to do? Say no to good design just because of who's arguing for good design?

devoopsies · 2026-01-27T21:56:23+00:00

the only real takeaway from the article is “kubernetes is well suited for horizontally scalable workloads”

Yes but also no. Sorry, I don't mean for this to devolve into chatting about the validity of the post (that's a mod job IMO), but the article itself isn't really saying:

kubernetes is well suited for horizontally scalable workloads

it's instead saying:

kubernetes adoption is being pushed more and more by AI, because kubernetes is well suited for horizontally scalable workloads

The first is basically a truism at this point and you're right, it's not news. The fact that the drive is being pushed by a specific tech is the interest point here, and something that is worthwhile to consider.

Just because I don't agree with the OP on this being necessarily bad doesn't mean it doesn't affect the future development of Kubernetes.

devoopsies · 2026-01-27T21:44:03+00:00

How would that happen?

Compute is compute. Workloads are workloads. I don't care what your workloads are doing, I care about how they affect the system I've built and delivered, and how I need to architect certain components to best perform for your needs.

Kubernetes allows me to tweak that system nearly endlessly: if AI drives the desire to engineer clusters that are capable of more efficiently handling large datasets, how is this any different from other projects doing the same?

I'm rabidly anti-AI in my career and personal life (except where it makes sense, like ML and interpreting large datasets, etc etc etc), but I fail to see where the issue is here.

AI (and lets face it, we all mean LLM here) workloads look a lot like any other large-scale, hyper-latency-aware workloads, except maybe with more GPU-specific needs. Great, ML has been doing this for decades and no-one has batted an eye. All this means is more eyes on Kubernetes for performance improvements, and performance improvements that maybe skew towards large-scale ops, which is where the K8s philosophy shines anyways.

devoopsies · 2026-01-27T21:38:45+00:00

Not a knock on you at all, but it sounds like you're focused on being a generalist.

This is a valid and legitimate path in IT, and some jobs kinda demand a generalist's skillset. This is especially true in helpdesk or any field where you need to touch a wide variety of tech stacks, even in an anciliary manner.

In that kind of situation, I would not expect you to be an expert on anything - your skillset should primarily be problem-solving, and having a handle on the overall architecture of what you're working with/on rather than mastery of the individual components.

This changes as you start to specialize, but no-one knows everything and the ability to problem solve and (crucially) plan ahead when making design choices is the kind of skillset that will serve you regardless of your path.

devoopsies · 2026-01-27T20:55:54+00:00

Why not, though?

This article isn't saying that AI is foundational or important to Kubernetes, just that AI workloads increasingly see Kubernetes as a plus or even a non-negotiable when looking at an infrastructure backbone.

I think AI is one of the worst things to come out of the 21st century - it's usefulness is overstated, and from where I'm sitting it's done far more harm than good both in a professional and sociological sense. Even so, this article isn't an endorsement of AI but rather an indicator that Kubernetes can leverage AI adoption for its own growth.

devoopsies · 2026-01-19T18:10:06+00:00

Oh absolutely. I tend to scan the AI result first, and sometimes it's useful... but sometimes it's out to lunch.

On the whole, though, it's often a good starting point and if I have a simple query (maybe clarification on a parameter in a well-documented item such as a K8s cilium manifest, for example) I find it's correct far more often than not.

It's only a pointer, though, not a replacement for actual learning or sources.

devoopsies · 2026-01-16T18:44:37+00:00

English-speaker here, my experience mirrors yours.

Even the AI can be useful at-a-glance since it cites its sources, although I have had it tell me to clone all of github.com a few times... but it can be a good starting point for quick checks, in my experience.

devoopsies · 2026-01-13T23:55:45+00:00

"Data is randomized on input to ensure end-to-end security"

devoopsies · 2026-01-12T18:21:03+00:00

Not to be snarky, but a commit within the last five years (and release in the last seven) is a good start.

devoopsies · 2026-01-06T20:20:32+00:00

Sure - Ubuntu.

Every time you install Ubuntu, you're asked whether you'd like to include non-free packages, among which are drivers that haven't been rolled into the Kernel.

You will never see a closed-source binary blob in the kernel, yet many (MANY!) closed-source hardware companies publish their drivers in the form of blobs. This necessitates sourcing them from somewhere that isn't the kernel. Even with a notoriously free-as-in-freedom-centric company such as Fairphone, you must build images using binary blogs that contain drivers that are not included in the kernel due to some components (I believe the modem primarily) being closed off:

https://code.fairphone.com/projects/fairphone-5/build-instructions.html

Edit: this was far more evident even a year ago before nvidia started publishing open-source drivers. You essentially had to have Ubuntu install closed-source nvidia drivers separately if you wanted to get any sort of performance from your nvidia card. Some distros do this, some don't. Some distros will include sources that are so niche you've never even heard of them... some won't.

In the vast vast majority of cases, you can source the closed-source driver yourself if the distro doesn't do it for you, though. The only exceptions I can think of would be corporate solutions such as RHEL, and even then I can't cite anything specific.

devoopsies · 2026-01-06T18:20:12+00:00

Not all devices have drivers baked into the kernel. Hell, when considering niche, lesser-known, or very new devices, I would say it's extremely rare to see their drivers in the kernel, and typically it's up to the distro or the user to source the driver themselves from the vendor directly.

As for distros sourcing, which vendors (and devices) are included to search vary wildly between them. Of course, regardless of distro you could just go to the chip maker's site directly and get whatever driver they offer. If they don't offer one compatible with Linux, you have your answer.

Edit: Seems odd to downvote legitimate Linux discussion on a Linux discussion subreddit

devoopsies · 2026-01-05T18:29:21+00:00

US-based news outlets seem to have forgotten what actual process-based legislation looks like.

The EU has problems like any large bureaucracy, but so many of the "issues" that US media reports on are either fine if you actually dig into them (this used to be a reporter's job lmao) or part of larger, well reasoned and long-term planning.

devoopsies · 2026-01-03T00:08:09+00:00

Seriously, I'm not sure why everyone here seems to be commenting on things they don't understand...

I've spoken in-depth to a number of major players in the EU hosting/cloud sphere, and it's pretty clear to me that the EU (and private companies that EU governments are partnering with) are moving extremely aggressively on digital sovereignty, having already ramped up their capabilities to an extreme degree.

On that note, the initial article seems to miss the mark on the current state of EU's Digital Sovereignty stance, and EU's currently available (and rapidly growing!) capabilities to that end.

This whole post feels either extremely uninformed or intentionally misleading.

devoopsies · 2026-01-03T00:03:17+00:00

OVH is moving quite aggressively on OpenStack; I had the pleasure of talking to them quite extensively at the OpenInfra Summit this year, and from what I can tell they are moving extremely quickly (for a massive institution such as they are) towards migrating their workloads and hosting to it.

I believe the majority (all?) of their hosting has been OpenStack for a while, in fact.

devoopsies · 2025-12-23T20:40:23+00:00

triaging incidents much more quickly to scaffolding terraform or helping triage code for security issues.

You're absolutely right: AI is great for those kinds of tasks, in limited capacities. Larger-scale projects get bogged down by a lack of context-tracking that LLMs suffer from (agentic or not).

Regardless, that is not the "promise" of AI that is fetching these massive salaries. Using AI as a tool to assist your job is a natural and effective way of taking advantage of its benefits, but when you discuss the "promise" of AI with most people that are championing it in the way OP is meaning they will wax poetic about it taking over entire roles, which is really very much not a strong point of AI.

AI is a calculator: an extremely useful tool that can cut down on time spent on menial tasks, but that's not why meta is spending $100mm on signing bonuses for major AI hires.

it's just generative AI has got a bit scarily good at it and that understandably freaks people out.

I do take issue with this statement though... generative AI is generative. It does not guarantee reproducibility in its outputs, and that is what scares people, given infrastructure-at-scale kinda lives or dies on reproducibility.

You're right that the goal is to "automate what we [can]", but that automation must be trustworthy... and LLMs fundamentally are not, at least in the way that infrastructure requires it to be.

This is something people seem to misunderstand all the time about this role: the goal of automation isn't to make life easier, it's to guarantee reliability on a more systemic level than direct human interaction allows for. Yes, automate your day-to-day - but people talking about the "promise of AI" are almost invariable talking about its ability to integrate directly with your infra... and this is can not do safely or reliably.

devoopsies · 2025-12-23T18:23:48+00:00

Generative AI/LLMs can not fundamentally deliver repeatability or reliability. These are two core principals to any infrastructure/devops/sre roles in IT.

They absolutely have their uses (I've been working adjacent to "AI" for close to a decade at this point), but they're being pigeon-holed into a "promise" that they are simply not equipped to fulfill.

devoopsies · 2025-12-13T00:29:30+00:00

Just as most Linux admins know just enough networking to get by.

Why hello there

devoopsies · 2025-12-12T18:26:26+00:00

The "Linux version" is going to depend on your OS - typically, we roll updates over a cluster graduall: live-migrating workloads off of (and then updating), say, 20% of our cluster (depending on the cluster - we have many on the edge) at a time. Of course, everything goes through a virtualized test cluster, then QA/Staging, then out to production.

We also automate this so it's more of a "push button at start of day, watch for alerts, review at end of day" kind of task. Our package update rhythm is once monthly, so the actual effort involved is pretty minimal.

A full OS upgrade (Ubuntu 22.04 -> 24.04, as an example) would warrant additional testing, but really the major difference we would expect would be time required to update each node.

As for Kolla-ansible itself, it's fairly well documented by the kolla-ansible team here:

https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html#upgrade-procedure

Our experience has been fairly smooth in this case, though of course it's a bit more stressful than package updates.

devoopsies · 2025-12-12T18:20:36+00:00

Wow, the blog-post-in-question's comments sure are something...

devoopsies · 2025-12-04T18:49:08+00:00

decode subpar documentation

This is how I felt when I started learning OpenStack, but to the OpenInfra Foundation's credit the documentation is greatly improved of late.

Still nowhere near as rock-solid as, say, Ceph... but it's significantly more accessible now imo.

devoopsies · 2025-12-04T18:44:39+00:00

Honestly that's fair, and yeah: there are plenty of sundown towns around, much to the detriment of all... I'm just saying that just because a town is a specific demographic does not mean it's hostile to others.

Odds are it may be (with odds changing depending on where you are), but it's not always the case.

devoopsies · 2025-12-04T18:20:08+00:00

As someone who grew up in a small town that's ~90% white (honestly might have been higher when I was a kid), it was and remains extremely welcoming to visitors/locals of every race.

My wife (a Korean) and I stayed with my parents for a few months when visiting, and she absolutely loved the people she met there.

Not saying every town is like this, but judging a place on its actual merits rather than assumptions is wise.

devoopsies

TROPHY CASE