Been Looking At New Models Lately, And Came Across Muse Glimmer, A 30B Model That’s Supposed To Be Really Good For Personal Use. Wanted To See If It Could Replace Gemma-4 As My Log-Summarizer Backend, Plus A Similar Role On My Personal Assistant. LM Studio Was Already Running On This Machine, So I Just Tried Loading It There. It Failed Immediately:
No module named 'mlx_vlm.speculative.drafters.muse_glimmer'
Had A Working GCP Weekly Digest Running On Google Apps Script For Weeks — Pulls Release Notes And Blog RSS Every Friday, Hands Them To Gemini To Write A Categorized Digest, Emails It Out, Archives A Copy To Google Drive. The Original Plan Was To Leave It Alone Until It Hit A Real Limit. Then A Different Reason To Migrate Showed Up: Wanted To Write This Up Next To The AWS Version As An “AWS vs GCP Serverless Digest Bot” Comparison, And Apps Script’s GmailApp/DriveApp/ScriptApp.getOAuthToken() Assume Every Reader Already Lives Inside A Google Account — Rebuilt It On Cloud Run Instead, Skipping The Original Migration Threshold On Purpose.
Part 1 Ended With Two Unresolved Questions: A 250Mi Memory Target For A Dashboard Container Actually Using Only 24Mi, Sitting Suspiciously Close To The 256Mi Limit Already On The Deployment, With No Citable Reason Why. And A CPU Number That Had Never Once Caught My Attention, The One I’d Waved Through Without Checking. The Plan Was To Let It Accumulate History And Come Back To See Which Way The Memory Target Went. A Month Later It Went A Third Way I Hadn’t Considered, The Answer Had Nothing To Do With The Limit, And It Closed Both Questions At Once.
Had Already Set Up VPA On A GKE Workload (A ClickHouse Backend, After It OOM’d Twice) And Assumed — Wrongly — That Vertical Pod Autoscaler Was Something GKE Provided As A Managed Feature. Turns Out The “Enable” Button On GKE Is Just Google’s Wrapper Around The Same Open-Source kubernetes/autoscaler Project Anyone Can Install Anywhere. Wanted To Confirm That For Real, So I Put It On A 6-Node Homelab RKE2 Cluster With No Cloud Provider In Sight.
It Went In Clean. What Wasn’t Clean Was The First Recommendation It Handed Back For A Live Workload — Ten Times The Container’s Actual Memory Usage, Within Minutes Of Being Installed.
Had Been Watching A LinkedIn Account Post AWS Updates Every Week For A While — Always Just Updates, And Kept Wondering If There Was A More Human Way To Deliver Them. So, Riding The AI Wave, Built A Lambda + Bedrock + SES + S3 Pipeline: Every Friday It Pulls The AWS What’s New And Blog RSS Feeds, Hands Them To Amazon Nova Pro To Write A Categorized Digest, Emails It Out, Archives A Copy To S3 — And Also Has Claude Opus Look At This Account’s Actual Resource Usage And Suggest Optimizations.
Needed To Wire All Of Akamai’s Data Into An Existing Grafana On GKE. Split Into Two Dashboards: CDN Data Rode On A Plugin That Was Already There, And WAF/Bot Logs Went Through A Small Proxy I Wrote Myself, Because The Only Grafana Plugin That Speaks Akamai’s SIEM API Is A Paid Third-Party One. Didn’t Want To Pay For It. (Cheapskate.)
Both pieces hit the same kind of bug: something that looks fixed, deploys clean, and still doesn’t work — with nothing useful in the logs to explain why.
After I got Keycloak wired up, logging into the dashboard started getting stuck. No error, no crash log. Just one of those situations where you feel like you’re missing something obvious and can’t see it. Today I tried again, and this time there was a clear error in the log: Invalid parameter: redirect_uri