Portal:Cloud VPS/Admin/Local customization and hacks

From Wikitech
Jump to navigation Jump to search

This page contains information about local customization and hacks for Cloud VPS's Openstack.

Originally started at https://phabricator.wikimedia.org/T324774

This is a mix of what makes Cloud VPS's identity and inherited technical debt. Some of these things worth keeping, others don't. In general, they are diversions from an common out-of-the-box openstack cloud deployment,


Openstack local customization and hacks for Cloud VPS
Name Component Tech debt Worth keeping Comment
Project IDs keystone yes yes? Forcing project id == project name (via code patch)
Custom roles & policies (RBAC) all no? no The observer/member/projectadmin roles. No big deal, but they are now kind of supported natively by upstream. See phab:T330759
VM hostname nova no? yes Constrain VM hostname via regex (via code patch)
designate-sink plugins designate no? yes Custom designate-sink plugin to create/destroy DNS entries on VM creation/deletion and to do other cleanup on VM deletion (puppet cert deletion, config cleanup, etc)
cinder-backups posix backend cinder yes? yes? Use of cinder-backup posix backend, which exists in upstream code but seems to generally not be used in many real deployments.
backported bugfixes all no yes Backported bugfixes for cinder, trove, neutron, etc
No BYOI glance no yes We don't allow bring your own VM image. No big deal.
Puppet for VMs glance no yes? Not really related to how we deploy openstack. No big deal.
LDAP integration glance, keystone no yes For Wikimedia Developer accounts etc. No big deal.
Cumin management glance no yes Not really related to how we deploy openstack. No big deal.
Horizon customization horizon no yes Removed some panels, added some other custom panels. No big deal.
neutron-linuxbridge-agent neutron yes no May no longer be supported upstream soon.
neutron flat network topology neutron no? no While fully upstream-supported use case, it greatly reduces what we can do with the SDN layer.
deploy via puppet & deb packages all yes? no Our custom puppet manifests are hand-crafted and not used by anyone else in the community. We are suspicious of the deb packages may also have little community usage?