Delivering continuous deployment of xen-api at cloud scale
summary
Rackspace shows a concrete path to continuous deployment for xen‑api: package OpenStack python services into a BitTorrent tarball per build, push it to hosts, switch symlinks and restart domU nova‑compute under mcollective orchestration so control plane code rolls weekly while guest VMs stay running. Key engineering details: dom0 uses zappy plugin versioning to avoid mismatches, RPC interfaces are versioned, DB migrations are the real blocker, and storage import/export (glance conversions, tapdisk limits) plus live OVS/libxl upgrades are the risky parts to solve.
AI-written summary · about
chapters (11)
- 0:00Continuous deployment intro
- 1:04Xen-API and OpenStack evolution
- 4:12XenServer architecture
- 9:03Control plane vs Nova compute
- 11:13Weekly deployments and versioning
- 13:18XenServer innovation platform
- 17:50Networking and storage issues
- 19:16Smoother upgrades and hotfixes
- 21:05Nova upgrade challenges
- 27:31Future XenServer and OpenStack ideas
- 30:18Q&A
related talks
27mLessons Learned from a Large Scale OpenStack Deployment with Tripleo
36mNo More Big Bang Operation – Keep Deploying Upstream OpenStack...
24mAutomating OpenStack Operations with Zuul
30mOpenStack Works, so now what?
23mOrchestration and CI/CD
21mBack to the original mission: an open cloud operating system
27mXen and the Art of Hypervisor Maintenance
57mWhat Is the Cloud?