I will be reallocating the database to cloudservices2002-dev, which has been imaged today.

Change 501539 had a related patch set uploaded (by Arturo Borrero Gonzalez; owner: Arturo Borrero Gonzalez):
[operations/puppet@production] openstack: codfw1dev: cloudservices2002-dev: include openldap profile

https://gerrit.wikimedia.org/r/501539

Change 501539 merged by Arturo Borrero Gonzalez:
[operations/puppet@production] openstack: codfw1dev: cloudservices2002-dev: include openldap profile

https://gerrit.wikimedia.org/r/501539

Change 501544 had a related patch set uploaded (by Arturo Borrero Gonzalez; owner: Arturo Borrero Gonzalez):
[operations/puppet@production] openstack: codfw1dev: cloudservices2002-dev introduce hiera keys for openldap

https://gerrit.wikimedia.org/r/501544

Change 501544 merged by Arturo Borrero Gonzalez:
[operations/puppet@production] openstack: codfw1dev: cloudservices2002-dev introduce hiera keys for openldap

https://gerrit.wikimedia.org/r/501544

Change 501550 had a related patch set uploaded (by Arturo Borrero Gonzalez; owner: Arturo Borrero Gonzalez):
[operations/puppet@production] acme_chief: generate certs for cloudservices2002-dev.wikimedia.org

https://gerrit.wikimedia.org/r/501550

Change 501550 merged by Arturo Borrero Gonzalez:
[operations/puppet@production] acme_chief: generate certs for cloudservices2002-dev.wikimedia.org

https://gerrit.wikimedia.org/r/501550

These test hosts don't use replication and are standalone, right? I think then we can simply do a "slapcat > foo.ldif" on the old trusty host, then stop slapd on the new stretch host and use slapadd to transfer the LDIF data.

I was planning to move this to clouddb2001-dev, but have noticed that that box is on a private vlan. I'm assuming we need ldap on a public vlan so that VMs can reach it, right? Or will VMs in the new codfw deploy also be on the private vlan?

Before any other change, I see this:

aborrero@clouddb2001-dev:~ $ sudo tcpdump -i any port 389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
14:56:10.581116 IP6 cloudservices2002-dev.wikimedia.org.44940 > clouddb2001-dev.codfw.wmnet.ldap: Flags [S], seq 1091679480, win 28800, options [mss 1440,sackOK,TS val 220844216 ecr 0,nop,wscale 9], length 0
14:56:14.709663 IP6 cloudservices2002-dev.wikimedia.org.44940 > clouddb2001-dev.codfw.wmnet.ldap: Flags [S], seq 1091679480, win 28800, options [mss 1440,sackOK,TS val 220845248 ecr 0,nop,wscale 9], length 0

i.e, a connection from a server with public IP reaching clouddb2001-dev which has private address.

In T218575#5107323, @Andrew wrote:

I was planning to move this to clouddb2001-dev, but have noticed that that box is on a private vlan. I'm assuming we need ldap on a public vlan so that VMs can reach it, right? Or will VMs in the new codfw deploy also be on the private vlan?

You were right. After yesterday conversation with @ayounsi, we can't do this. We will need to build the LDAP server in cloudservices2002-dev.wikimedia.org or elsewhere.

ldap on cloudservices2002-dev is populated now, thanks to Moritz's suggestion.

I was a bit surprised to find ldap already installed on that host... is that all puppetized already?

In T218575#5125659, @Andrew wrote:

ldap on cloudservices2002-dev is populated now, thanks to Moritz's suggestion.

I was a bit surprised to find ldap already installed on that host... is that all puppetized already?

Thanks! Yes, I think I added openldap in preparation for the near future.

class role::wmcs::openstack::codfw1dev::services {
    system::role { $name: }
    include ::standard
    include ::profile::base::firewall
    include ::profile::openstack::codfw1dev::pdns::auth::db
    include ::profile::openstack::codfw1dev::pdns::auth::service
    include ::profile::openstack::codfw1dev::pdns::recursor::service
    include ::profile::openstack::codfw1dev::designate::service
    include ::profile::openldap                    <------------------
}

Mentioned in SAL (#wikimedia-cloud) [2019-04-22T11:14:15Z] <arturo> create by hand /var/cache/labsaliaser/labs-ip-aliases.json in cloudservices2002-dev (T218575)

I just created the /var/cache/labsaliaser/labs-ip-aliases.json file in cloudservices2002-dev with content {"aliasmapping": {}, "extra_records": {"puppet.": "208.80.153.108"}} to silence a pdns daemon error. This is in puppet, so not sure why is not showing up in the server.

Also, I will proceed with T218022: decommission: labtestservices2001.wikimedia.org now that @Andrew managed to rescue the LDAP database.