Jump to content

Ldap hosts

From Wikitech

Yes 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 Yes Done
  • Move default puppet node classes out of ldap and into heira Yes Done
  • Replace our reliance ldap for instance name and project name with nova metadata Yes Done
  • Move public DNS records out of ldap and into designate/pdns Yes Done
  • Blocked pending a move to Horizon where there is a ready-made webUI for this Yes Done
  • Replace the ldap-based instance puppet configuration Yes Done
  • Blocked pending development of a webUI for this Yes Done

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. 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. 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.
  3. 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
  1. 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.