Ldap hosts
Done Labs ldap host entries are now a thing of the past.
Welcome to the future
We've made a great deal of progress towards the goals in this document. Here's a checklist:
- Move private DNS out of ldap and into designate Done
- Move default puppet node classes out of ldap and into heira Done
- Replace our reliance ldap for instance name and project name with nova metadata Done
- Move public DNS records out of ldap and into designate/pdns Done
- Blocked pending a move to Horizon where there is a ready-made webUI for this Done
- Blocked pending a move to Horizon where there is a ready-made webUI for this
- Replace the ldap-based instance puppet configuration Done
- Blocked pending development of a webUI for this Done
- Blocked pending development of a webUI for this
How things worked before we started making changes
Currently, the OpenStackManager manages the LDAP host records, as detailed below. Host records are consumed by PowerDNS, Puppetmaster, Shinken, NFS export scripts, and OpenStackManager.
The goal of this project is, primarily, to eliminate reliance on OpenStackManager to manage these records. Eliminating our use of LDAP in this capacity entirely would be a bonus.
Standard host record
# i-000000ee.eqiad1.wikimedia.cloud, hosts, wikimedia.org dn: dc=i-000000ee.eqiad1.wikimedia.cloud,ou=hosts,dc=wikimedia,dc=org [1] objectClass: domainrelatedobject [1] objectClass: dnsdomain [1] objectClass: puppetclient [1] objectClass: domain objectClass: dcobject [1] objectClass: top puppetVar: realm=labs puppetVar: instanceproject=testlabs [1] puppetVar: instancename=util-abogott [1] puppetClass: base [2] puppetClass: role::labs::instance [2] l: eqiad [1] associatedDomain: i-000000ee.eqiad1.wikimedia.cloud [1] associatedDomain: util-abogott.eqiad1.wikimedia.cloud [1] dc: i-000000ee.eqiad1.wikimedia.cloud aRecord: 10.68.16.19 [3]
- ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 Added by OSM (addHostFromInstance) after nova creates the instance.
- ↑ 2.0 2.1 Added by OSM (addHostFromInstance) after nova creates the instance. These values can also be altered later by user interaction with the web interface.
- ↑ Added by OSM (addHostFromInstance) or, in case the IP is not assigned, OpenStackNovaHostJob via the jobqueue. Job is resubmitted if the instance still exists but nova has not yet assigned it an IP
Public IP record
# 208.80.155.192, hosts, wikimedia.org [1] dn: dc=208.80.155.192,ou=hosts,dc=wikimedia,dc=org objectClass: domainrelatedobject objectClass: dnsdomain objectClass: domain objectClass: dcobject objectClass: top associatedDomain: util-abogott.wmflabs.org dc: 208.80.155.192 aRecord: 208.80.155.192
- ↑ Records like this can be added or removed at any time via user interaction
Potential replacements
Private IP records
Nova DNS
Andrew originally implemented a compact DNS implementation within Nova which we never adopted. The feature is still present in the Nova code, and implements our use case of PDNS/LDAP.
Adopting this would be fairly simple, with a few caveats. The DNS implementation in Nova uses a different schema from our current DNS implementation, so we'd need to run a big rename on our LDAP database. Additionally, our current ordering of LDAP host record creation would be disrupted so we might have to move all the puppet record creation into the jobqueue, or maintain separate LDAP records for puppet and DNS.
One major flaw in the Nova DNS implementation is that records are created based on the instance name rather than the ID. That leaves a potential for naming collisions. We currently enforce uniqueness in instance names, but the enforcement mechanism isn't perfect and it would be nice to not require this.
Designate
Designate is a project in OpenStack incubation, the frontrunner for becoming the official OpenStack DNS solution.
Due to rapid development, it's difficult to determine what features Designate provides in versions that are compatible with our current Nova cluster (running version IceHouse). The documentation implies that Designate supports PDNS with LDAP, our current use case, but that proves not to actually be the case (the LDAP backend has been deprecated for PDNS so the Designate devs have little interest in implementing it.)
Writing a PDNS/LDAP backend for Designate would not be a very big job, but given our ambivalence about PDNS and LDAP anyway, it might be best to consider switching to a different backend and pulling DNS records out of LDAP entirely. Designate is documented as support PowerDNS, BIND and MySQL BIND as backends.
Adopting Designate with an existing backend should be straightforward -- it may require some custom package work or an upgrade of our OpenStack cluster, and a lot of migration from the old DNS records to the new system. Presuming that it's possible to back the new implementation with the old one, that migration should be possible without downtime.
UPDATE: Designate is now running on server Holmium and creating private DNS records for new labs instances.
Something else
Hooking Nova instance creation and deletion is not that hard, so this particular task could accomplished via any number of homemade solutions, for instance a custom python nova extension. If third party solutions really let us down, this is a potential fallback.
Public IP records
Nova DNS and Designate each provides a REST interface for manipulating public DNS records. There seems to be a project to implement a GUI for Designate, here: https://github.com/openstack/designate/tree/master/contrib/designate-dashboard
Since public DNS manipulation is a fairly rare occurrence, we don't need this feature in order for Horizon to be useful. We do need it in order to deprecate OSM entirely, though.
Puppet configuration
Probably this could be handled entirely with hiera, thus eliminating the puppetmaster's reliance on LDAP entirely. Of course, there would have to be some sort of UI for manipulating the hiera records, ideally something prettier than our curent yaml-on-a-wikipage solution.
The host records may still be used for cert signing -- this needs research.
NFS Scripts
TBD
Host records, remnants
If all of the above are completed, it should be possible to remove instance information from LDAP entirely. More research is needed to verify that this list of dependencies is complete.