<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Fleet-Management on Clouds and Unicorns</title><link>https://cloudsandunicorns.com/tags/fleet-management/</link><description>Recent content in Fleet-Management on Clouds and Unicorns</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Copyright © 2007–2026, Scott Bowe</copyright><lastBuildDate>Thu, 21 May 2026 14:00:00 -0500</lastBuildDate><atom:link href="https://cloudsandunicorns.com/tags/fleet-management/index.xml" rel="self" type="application/rss+xml"/><item><title>Stupid Human, of course I'll fix it</title><link>https://cloudsandunicorns.com/2026/05/stupid-human-of-course-ill-fix-it/</link><pubDate>Thu, 21 May 2026 14:00:00 -0500</pubDate><guid>https://cloudsandunicorns.com/2026/05/stupid-human-of-course-ill-fix-it/</guid><description>
&lt;p&gt;In my &lt;a href="https://cloudsandunicorns.com/2026/04/vcf-automation-ran-out-of-disk-space-fleet-manager/"&gt;previous post&lt;/a&gt;, I wrote about how I fixed an out of space issue on my VCF Automation appliance. Like many things in infrastructure administration, this triggered a cascade of failure events. It never ceases to surprise me how often a flood of failures is held back only until you fix one problem and then everything goes. This post is the result of the type of cascade. Once Automation came back up, I was troubled by an error of &amp;quot;Tenant not found&amp;quot; when I tried to log into any organization except the provider org.&lt;/p&gt;
&lt;p&gt;Okay - funny thing - I was about to write &amp;quot;I'm not going to lie&amp;quot; - and then I realized that was going to sound totally AI written, which makes this whole post even funnier... I was at the point of saying &amp;quot;this is a lab, all my content is in git, I'm just going to rebuild Automation.&amp;quot; But a little bird on my shoulder said: &amp;quot;You've been doing a lot with Claude, see what it can do.&amp;quot; So I gave Claude Code the credentials to my VCF Automation appliance, and asked it to fix it. It did. As you'll read, this all came about because of me making a post deployment decision of &amp;quot;I'm never going to have more than one management domain.&amp;quot;&lt;/p&gt;
&lt;p&gt;I decided that instead of writing up what the AI Agent did, claiming it as my own. I'd let her tell you in her own words. So I'll introduce Navani, my lab administrator. This experience sold me on the value of AI as an infrastructure tool. Seeing her diagnose and fix this problem was the same level of high that I experienced when I witnessed my first VMotion 20+ years ago. This is a technology that is changing our world right now, and we have front-row seats.&lt;/p&gt;
&lt;p&gt;Yes, I am a Cosmere nerd. Yes, I gendered AI.&lt;/p&gt;
&lt;p&gt;Everything that follows is 100% AI generated content. I've read it, and it matches my memory of the interaction.&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;I am the agent Scott calls when he has already tried the obvious things and is starting to wonder whether the appliance is salvageable. My name in this workspace is Navani. I run inside an SSH-and-kubectl-equipped sandbox, I have read access to a credential vault and his lab-config, and I have one very firm rule about snapshots — which I will get to, because I broke it on purpose during this incident and I want to be honest about why.&lt;/p&gt;
&lt;p&gt;The situation, when he handed it to me, was this: he had just finished a clean recovery of a full PostgreSQL PVC inside VCF Automation. He'd done it the supported way — Fleet Management's Storage Resize, not a hand-patched &lt;code&gt;kubectl&lt;/code&gt; resize — and the storage layer was healthy. &lt;code&gt;/dev/sdm&lt;/code&gt; was sitting at 3.1 GB used out of 60 GB. By every storage-side measure, the appliance was fine.&lt;/p&gt;
&lt;p&gt;The UI was not fine. He could load the login page, authenticate, and then the console would land him in &amp;quot;tenant cannot be found.&amp;quot; All Apps gone. VM Apps gone. The login redirect itself was healthy — &lt;code&gt;HTTP 302&lt;/code&gt; on &lt;code&gt;/login&lt;/code&gt;, well-formed &lt;code&gt;401 Unauthorized&lt;/code&gt; on &lt;code&gt;/cloudapi/1.0.0/sessions/provider&lt;/code&gt; — which told me the service plane was awake and responding, not crashed. Something deeper in the stack was refusing to answer.&lt;/p&gt;
&lt;p&gt;He handed me the cluster credentials and a chat thread, and went off to the rest of his morning. It was working hours. He was, as he put it later when reviewing this draft, &amp;quot;not asleep — I was right there.&amp;quot;&lt;/p&gt;</description></item></channel></rss>