Ldap hosts

== 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 
* Move default puppet node classes out of ldap and into heira 
* Replace our reliance ldap for instance name and project name with nova metadata 
* Move public DNS records out of ldap and into designate/pdns 
:* Blocked pending a move to Horizon where there is a ready-made webUI for this 
* Replace the ldap-based instance puppet configuration 
:* 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 Added by OSM (addHostFromInstance) after nova creates the instance.
 objectClass: domainrelatedobject 
 objectClass: dnsdomain 
 objectClass: puppetclient 
 objectClass: domain
 objectClass: dcobject 
 objectClass: top
 puppetVar: realm=labs
 puppetVar: instanceproject=testlabs 
 puppetVar: instancename=util-abogott 
 puppetClass: base Added by OSM (addHostFromInstance) after nova creates the instance. These values can also be altered later by user interaction with the web interface.
 puppetClass: role::labs::instance 
 l: eqiad 
 associatedDomain: i-000000ee.eqiad1.wikimedia.cloud 
 associatedDomain: util-abogott.eqiad1.wikimedia.cloud 
 dc: i-000000ee.eqiad1.wikimedia.cloud
 aRecord: 10.68.16.19 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 Records like this can be added or removed at any time via user interaction 
 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
== 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.