Done with no major issues apparently.

I would like to propose these 2 totally untested patches:

Closing this task as resolved. The try/testing was completed. I will follow up on T221205: Toolforge: deploy sssd to tools-sgewebgrid* nodes and others.

@Papaul please update switch port description and physical labeling for this server, it was renamed from labtestcontrol2003 to cloudcontrol2003-dev.

In T217891#5106883, @Gilles wrote:

FYI, deployed a mediawiki config change just now and got this:

11:39:41 Started sync-apaches
11:44:06 ['/usr/bin/scap', 'pull', '--no-update-l10n', '--include', 'wmf-config', '--include', 'wmf-config/InitialiseSettings.php', 'mw1268.eqiad.wmnet', 'mw1314.eqiad.wmnet', 'mw2255.codfw.wmnet', 'mw2290.codfw.wmnet', 'mw2216.codfw.wmnet', 'mw1251.eqiad.wmnet', 'mw2188.codfw.wmnet', 'mw1320.eqiad.wmnet', 'mw1285.eqiad.wmnet'] on cloudweb2001-dev.wikimedia.org returned [255]: ssh: connect to host cloudweb2001-dev.wikimedia.org port 22: Connection timed out

sync-apaches: 100% (ok: 262; fail: 1; left: 0)

This should be done now.

The bootstrap should be now complete. Will open separate tasks for non-working stuff we may discover.

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?

In T214370#5111910, @Papaul wrote:

@aborrero the server has 3 nic's connected to the switch and the third NIC has a description but it is disable

ge-5/0/11       down  down labtestneutron2002-eth2-disable

Do you plan on using the third NIC or is ok for me to remove it?

Before any other change, I see this:

We won't be doing this anytime soon. Will re-evaluate in the next FY19/20.

In T209707#5107316, @Andrew wrote:

Installing cloudvirt1024 with Buster isn't really an option -- we'd have to port all OpenStack packages for versions M and N to Buster just to keep this one server alive -- we won't otherwise be running M or N on Buster at all, we'll have otherwise upgraded to O or P before we update the rest of our cluster to Buster. That's a lot of ported packages to manage (dozens, possibly as many as 100) just to work around this one issue.

@aborrero can chime in with what would actually be involved but I expect it's a lot.

By the time of this phab comment, cloudweb2001-dev.wikimedia.org is a spare system waiting to be put into service soon. We can safely drop cloudweb2001-dev from any scap configuration meanwhile.

This should be done now.

I just imported the codfw1dev-r keystone, nova, glance, neutron databases into cloudcontrol2001-dev.codfw.wmnet:

See https://phabricator.wikimedia.org/T220096#5103616, I just reallocated the striker database to clouddb2001-dev.codfw.wmnet. I will proceed with decommissioning this server.

I just imported the striker database from labtestweb2001 into this server:

Status update:

Those SAL messages are a typo in the phabricator task number. My fault, sorry for the noise.

In T220530#5098231, @Bstorm wrote:

The full name is clouddb1001.clouddb-services.eqiad.wmflabs, but you almost certainly need to use 172.16.7.153 instead unless we can resolve the DNS outside cloud in the future.

There has been a confusion briefly in this phab task (my fault)

• the cloudnet2002-dev.codfw.wmnet server https://netbox.wikimedia.org/dcim/devices/839/ is not taking any changes or reimages or renames or anything. Left as is.
• this ticket and all the related changes are for labtestnet2002.codfw.wmnet https://netbox.wikimedia.org/dcim/devices/1685/

In T220426#5097145, @gerritbot wrote:

Change 502476 had a related patch set uploaded (by Arturo Borrero Gonzalez; owner: Arturo Borrero Gonzalez):
[operations/dns@master] cloudnet2002-dev: rename to cloudweb2001-dev.wikimedia.org

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

Could you please update the docs at https://wikitech.wikimedia.org/wiki/Help:Puppet-compiler#Catalog_compiler_for_CloudVPS

the shortened interface name Exec[/sbin/ifup p175s0f1d1.1105] looks even more confusing, seems to be some random string. Perhaps it makes sense to selectively disable the predictable names in some cases like these.

Please @Papaul :

• refresh physical labels for this server
• refresh switch ports labels for this server
• drop eth1 config for this server in the switch (should have the virt-specific trunk, which we no longer require)

We will be doing T220129: labtestmetal2001.codfw.wmnet: rename to clouddb2001-dev and reimage to stretch in codfw1dev. Closing task now that we have concrete plans for it.

In https://phabricator.wikimedia.org/T217891#5088745 we decided that the database will be hosted in clouddb2001-dev.codfw.wmnet, which will be created in T220129: labtestmetal2001.codfw.wmnet: rename to clouddb2001-dev and reimage to stretch in codfw1dev

Not sure if I should drop the concrete registers in the puppetdb, or if cleaning the node is enough.

Per conversation with @Andrew on IRC: