OpenStack Liberty Private Cloud HowTo
OpenStack Liberty (October 2015) was the 12th release and introduced major features like role-based access control (RBAC) for Neutron networks, Ironic bare-metal integration, and Manila shared filesystems. While Liberty is long past end-of-life, this guide serves as a historical reference and migration guide for operators still running Liberty.
Liberty Release Highlights
| Feature | Service | Significance |
|---|---|---|
| Network RBAC | Neutron | Share networks with specific projects |
| Bare metal provisioning | Ironic | First-class bare-metal support |
| Shared filesystems | Manila | NFS/CIFS as a service |
| Rolling upgrades | Nova | Upgrade compute nodes without downtime |
| JSON Home for APIs | Keystone | Better API discoverability |
| Tag support | Nova | Tag instances for organization |
Why You Should Migrate Away from Liberty
Liberty reached end-of-life in November 2016. Running it in 2024+ poses serious risks:
| Risk | Details |
|---|---|
| No security patches | Known CVEs are unpatched |
| Python 2 only | Python 2 reached EOL January 2020 |
| No vendor support | All vendors dropped Liberty support |
| Missing features | 9 years of improvements unavailable |
| Driver compatibility | Modern hardware lacks Liberty drivers |
Original Liberty Architecture
A typical Liberty private cloud used:
Controller Node(s):
- Keystone (identity)
- Nova API + scheduler + conductor
- Neutron server
- Glance (images)
- Cinder API + scheduler
- Horizon (dashboard)
- MariaDB + RabbitMQ
Network Node(s):
- Neutron L3 agent
- Neutron DHCP agent
- Neutron metadata agent
- Open vSwitch
Compute Node(s):
- Nova compute
- Neutron OVS agent
- libvirt + KVM
Storage:
- Cinder volume (LVM, Ceph, or NetApp)
Liberty Installation (Historical Reference)
The official Liberty install guide used manual package installation on Ubuntu 14.04 or CentOS 7.
Keystone Setup (Liberty)
# Ubuntu 14.04 packages
sudo apt install keystone apache2 libapache2-mod-wsgi
# Configure
sudo vim /etc/keystone/keystone.conf
# [database]
# connection = mysql+pymysql://keystone:PASS@controller/keystone
# [token]
# provider = uuid
# driver = memcache
sudo keystone-manage db_sync
Nova Setup (Liberty)
sudo apt install nova-api nova-cert nova-conductor \
nova-consoleauth nova-novncproxy nova-scheduler
Note: nova-cert and nova-consoleauth were removed in later releases.
Neutron Setup (Liberty)
Liberty primarily used ML2 with Open vSwitch:
# /etc/neutron/plugins/ml2/ml2_conf.ini
[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vxlan
mechanism_drivers = openvswitch,l2population
Migration Path: Liberty to Current
Direct upgrade from Liberty to 2024.2 Dalmatian is not possible. You must follow the sequential upgrade path:
Liberty (2015.2) → Mitaka → Newton → Ocata → Pike → Queens → Rocky →
Stein → Train → Ussuri → Victoria → Wallaby → Xena → Yoga →
Zed → 2023.1 → 2023.2 → 2024.1 → 2024.2
This is 19 sequential upgrades, which is impractical. The recommended approach is parallel migration.
Parallel Migration Strategy
- Deploy a new 2024.2 Dalmatian cloud alongside Liberty
- Migrate data, not infrastructure:
- Export Glance images and re-import
- Snapshot and recreate instances
- Export Cinder volumes and re-import
- Recreate Neutron networks and security groups
- Migrate users via Keystone export/import or LDAP cutover
- Decommission the Liberty cloud
Migrating Glance Images
# On Liberty cloud
glance image-download --file ubuntu.raw <image-id>
# On Dalmatian cloud
openstack image create --disk-format raw --container-format bare \
--file ubuntu.raw "Ubuntu (migrated)"
Migrating Instances
# On Liberty: snapshot the instance
nova image-create <instance-id> instance-snapshot
glance image-download --file snapshot.raw <snapshot-id>
# On Dalmatian: import and boot
openstack image create --file snapshot.raw --disk-format raw \
--container-format bare instance-snapshot
openstack server create --image instance-snapshot \
--flavor m1.medium --network new-net migrated-vm
Migrating Cinder Volumes
# On Liberty: create backup or download
cinder backup-create <volume-id>
# Or export raw:
rbd export volumes/<volume-rbd-name> volume.raw
# On Dalmatian: import
openstack volume create --size <size> migrated-vol
rbd import volume.raw volumes/<new-volume-rbd-name>
Key Differences: Liberty vs 2024.2 Dalmatian
| Feature | Liberty (2015) | Dalmatian (2024) |
|---|---|---|
| Python version | 2.7 | 3.10+ |
| Networking default | OVS + L3 agent | OVN |
| Auth tokens | UUID | Fernet (no DB) |
| Placement | Part of Nova | Separate service |
| Cells | Nova Cells v1 | Cells v2 |
| Dashboard | Horizon only | Horizon + Skyline |
| Deployment tools | Manual / Fuel | Kolla-Ansible, OSA |
| Container support | None | Zun, Magnum |
| Load balancing | LBaaS v1 | Octavia |
Lessons from Liberty-Era Deployments
- Automate from day one — Manual deployments are impossible to upgrade
- Use supported deployment tools — Kolla-Ansible or OSA
- Plan for upgrades — Skip-level upgrades (SLURP) in modern OpenStack help
- Separate control and data planes — Makes upgrades less risky
- Use Ceph — Storage portability is critical for migrations
Summary
OpenStack Liberty was a milestone release, but it has been unsupported since 2016. If you are still running Liberty, the practical migration path is to deploy a new 2024.2 Dalmatian cloud and migrate workloads in parallel rather than attempting sequential upgrades.