🌅 Deploying the Skyline Dashboard for OpenStack with AI

Horizon has served OpenStack faithfully for over a decade, but it shows its age — heavy Django, dated UI, sluggish on large clouds. When I first saw OpenStack Skyline, the newer dashboard project, the pitch landed immediately: a modern Vue front end, a lightweight Python gateway, and a UI that does not make users feel like they time-traveled to 2014. Skyline is increasingly the default dashboard in fresh deployments, and migrating to it is a question more operators are facing.

Deploying Skyline means standing up its gateway, wiring it to Keystone, and getting the front-end build right — a chain of config steps where any single misconfiguration leaves you at a login page that will not log in. This is config-grind territory, which is exactly where I lean on an AI assistant as my fast junior engineer: it drafts the config files and systemd units, I verify every endpoint URL, and it never touches the running cloud or my credentials.

The Two Pieces of Skyline

Skyline splits into skyline-apiserver (the Python gateway that talks to OpenStack APIs) and skyline-console (the Vue front end). The gateway reads a YAML config pointing at Keystone and the other service endpoints. Before deploying, confirm the APIs Skyline will front are healthy:

openstack endpoint list
openstack token issue

If token issue fails, Skyline’s login will fail too — the gateway just proxies Keystone auth. Establishing that the backend is healthy before blaming Skyline is the first lesson, and the first thing I tell the AI when describing a symptom.

Configuring the Gateway

The gateway config (skyline.yaml) needs your Keystone URL, a system admin account for Skyline, and the database connection. Generating this YAML by hand is exactly the tedious, typo-prone work I delegate. I describe my Keystone endpoint and database, and the model produces a structured skyline.yaml. Then I verify the auth URL and the system_admin project scope by hand — a wrong scope means Skyline cannot enumerate projects and shows an empty dashboard to everyone.

After config, initialize the database and start the gateway:

make db_sync
skyline-apiserver

Pro Tip: Skyline’s gateway must reach the internal Keystone endpoint, not just the public one. A surprising number of “Skyline cannot log in” failures are the gateway pointed at a public URL it cannot route to from inside the control plane — check that endpoint URL first, before anything else.

Serving the Console

The Vue console is static assets served behind nginx, proxying API calls to the gateway. A minimal nginx block proxies /api to the gateway and serves the built assets for everything else. I have AI draft the nginx config from a description of my ports and paths — it knows the proxy_pass and try_files patterns cold — and then I diff it against my real layout. A wrong proxy_pass here is the classic “the page loads but nothing works” symptom.

Running Skyline Under systemd

For anything beyond a quick test, you want the gateway managed by systemd so it restarts on failure and survives reboots. The unit is straightforward but the details matter — the working directory, the user, and the path to the config all have to be right, or the gateway starts and immediately dies. This is classic boilerplate I hand to AI:

sudo systemctl status skyline-apiserver
sudo journalctl -u skyline-apiserver -n 50

I describe my install path and the user Skyline should run as, the model drafts the unit file, and I verify the ExecStart path and the config location against my actual layout. The model knows systemd conventions perfectly; it does not know where I installed Skyline. After enabling the unit, journalctl is where the gateway’s startup errors surface — and pasting those into the AI turns a cryptic Python traceback at boot into a clear “your config path is wrong” in seconds. A gateway that will not stay up is almost always a unit-file path problem, and checking the journal first saves you from debugging the wrong layer.

Debugging the Login Loop

The signature Skyline failure is the login that bounces you straight back to the login page. The cause is almost always one of: gateway cannot reach Keystone, the system admin credentials are wrong, or a cookie/CORS mismatch between console and gateway. I pull the gateway logs and paste them into Claude with the question “which of these three is causing the bounce?” The model reads the auth flow in the logs faster than I do and points at the broken link in the chain.

When a Skyline rollout breaks login for everyone — and it will, at least once — I log the investigation in my incident response dashboard so the next person inherits the fix.

Migrating from Horizon

You do not have to choose overnight. I run Skyline and Horizon side by side on different hostnames during migration, point a pilot group at Skyline, and collect feedback before flipping everyone. Both read the same Keystone, so there is no data migration — just two front ends on one cloud. I ask AI to draft a comparison checklist of which panels each pilot user relies on, so I can confirm Skyline covers their actual workflows before cutover.

Guardrails

A dashboard misconfiguration can lock out your entire user base, so even though Skyline provisions nothing itself, its blast radius is everyone who logs in. My rules:

• The AI drafts gateway YAML, nginx config, and systemd units; it never edits the live config or restarts the production gateway itself.
• I deploy to a staging hostname first and keep a known-good config backup for one-command rollback.
• Every endpoint URL the model writes gets verified against the real endpoint list before it goes live.

Because Skyline deployment is real config-as-code, I run the YAML and nginx changes through my code review dashboard before shipping. My vetted Skyline prompts live in the prompt workspace, reusable templates are in the OpenStack prompt pack, and I edit the config files in Cursor.

The Takeaway

Skyline is the dashboard upgrade most OpenStack clouds will eventually make, and the deployment is more config plumbing than rocket science — which makes it a perfect fit for an AI assistant that drafts the YAML and nginx while you verify the endpoints. Keep the model in the junior-engineer lane, deploy to staging first, and your users get a modern dashboard without you spending a weekend fighting a login loop.

The strategic reason to make the move is momentum: Skyline is where the dashboard development energy now lives, and clouds that migrate early ride that momentum instead of fighting Horizon’s aging stack. The side-by-side migration path means there is no big-bang risk — you pilot, you gather feedback, you flip when you are ready. An AI assistant compresses the config-plumbing phase so the only thing left to spend time on is the part that actually deserves it: confirming Skyline covers every workflow your users depend on before you turn Horizon off.

If you want help planning a clean Horizon-to-Skyline migration, work with me, or keep exploring the OpenStack guides and the prompt library.