Page MenuHomePhabricator

domain inconsistencies with new VMs
Closed, ResolvedPublic


Newly created VMs regard their domain as <project>.eqiad.wmflabs. For example:

root@cumin:~# hostname -f

Designate is putting them in the new domain, <project>

We should probably standardize things one way or another. Is it safe to move forward with having new VMs know their actual new-style domain?

Event Timeline

Andrew created this task.Jul 30 2020, 2:28 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 30 2020, 2:28 PM
Kormat added a subscriber: Kormat.Jul 30 2020, 2:30 PM
bd808 added a subscriber: bd808.Jul 30 2020, 3:18 PM

I can't remember, was there something that stopped us from doing this earlier? I have a vague memory of something (puppet?) being broken for a bit when you first added the new naming scheme.

I think throwing the switch here is fine personally. It does need to be announced, but I don't think it needs anything like an opt-in period or a long lead up. I'd say a News page on wikitech plus an email to cloud-announce@ is enough.

Would this also be a good point to stop making the legacy aliases for each host that omit the project name? I can't remember if we have deeper issues that make that something we keep around (like our hack to still use project names instead of uuids).

One issue the conversion is likely to trip over is hiera settings using the old naming scheme. Maybe that won't be a large issue if existing instances keep there "primary" name? I can image some project admins wanting all their instances to be consistent though, so there might be an ask for a tutorial on how to rename existing instances.

$ cd instance-puppet
$ git grep -l eqiad.wmflabs | cut -d/ -f1 | sort | uniq -c | sort -nr
  89 deployment-prep
  18 tools
  11 toolsbeta
   8 project-proxy
   8 cloudinfra
   8 automation-framework
   7 traffic
   7 testlabs
   6 integration
   5 sso
   5 openstack
   4 clouddb-services
   3 wikidata-query
   3 paws
   3 monitoring
   3 cloudstore
   3 analytics
   2 striker
   2 search
   2 puppet
   2 phabricator
   2 maps
   2 git
   1 wikidata-dev
   1 techblog
   1 shinken
   1 services
   1 security-tools
   1 puppet-diffs
   1 planet
   1 packaging
   1 ores-staging
   1 ores
   1 mediawiki-vagrant
   1 math
   1 mariadb104-test
   1 lta-tracker
   1 logging
   1 hound
   1 devtools
bd808 updated the task description. (Show Details)Aug 5 2020, 3:24 PM
Andrew added a comment.Aug 5 2020, 3:36 PM

I'm going to send notice that we'll start this transition in early September, text tbd

I'm currently bravely renaming my VMs to the new domain.

One issue i ran into is that /etc/resolv.conf gets populated with the old domain (eqiad.wmflabs). This is because base::resolving looks up labs_tld and labs_site in hiera for labs hosts. labs_tld is set to wmflabs in hieradata/common.yaml, and labs_site isn't set, so it defaults to ::site.

Change 621685 had a related patch set uploaded (by Kormat; owner: Kormat):
[operations/puppet@production] pontoon/mariadb104-test: Move to new domain

Change 621685 merged by Kormat:
[operations/puppet@production] pontoon/mariadb104-test: Move to new domain

Andrew closed this task as Resolved.Sep 8 2020, 4:36 PM
Andrew claimed this task.

this should be fixed now; everything new is in