This is also a good time remind everyone to update their ProxyJump configuration [1] to include the new TLDs. At least I would have forgotten it if I had not seen this remidner.

[1] https://wikitech.wikimedia.org/wiki/Help:Accessing_Cloud_VPS_instances#Proxy...)

On Mon, Sep 7, 2020 at 2:31 PM Andrew Bogott abogott@wikimedia.org wrote:

Reminder: This naming change is happening tomorrow, less than 24 hours from now. Update your .ssh/config now so you aren't confused tomorrow!

-Andrew

-------- Forwarded Message -------- Subject: Phasing out the .wmflabs tld on September 8th Date: Wed, 19 Aug 2020 08:55:18 -0500 From: Andrew Bogott andrewbogott@gmail.com andrewbogott@gmail.com Reply-To: andrewbogott@gmail.com To: Cloud-announce@lists.wikimedia.org

tl;dr:

VMs created on or after September 8th will stop having .eqiad.wmflabs domains, and be found only under .eqiad1.wikimedia.cloud

The whole story:

Currently cloud-vps VMs stand astride two worlds: wmflabs and wikimedia.cloud. Here's the status quo:

• New VMs get three different DNS entries:

hostname.project.eqiad1.wikimedia.cloud, hostname.project.eqiad.wmflabs, and hostname.eqiad.wmflabs [0]

• Reverse DNS lookups return hostnames under eqiad1.wikimedia.cloud

• VMs themselves believe (e.g. via hostname -f) that they're still under

eqiad.wmflabs

That hybrid system has done a good job maintaining backwards compatibility, but it's a bit of a mess. In the interest of simplifying, standardizing, and eliminating ever more uses of the term 'labs', we're going to start phasing out the wmflabs domain name. Beginning on September 8th, new VMs will no longer receive any naming associated with .wmflabs [1].

• New VMs will get one DNS entry: hostname.project.eqiad1.wikimedia.cloud

• New VMs will continue to have a pointer DNS entry that refers to the

.wikimedia.cloud name

• New VMs will be assigned an internal hostname under .wikimedia.cloud

In order to avoid breaking existing systems, these changes will NOT be applied retroactively to existing VMs. Old DNS entries will live on until the VM is deleted and should be largely harmless. If, however, you find yourself rewriting code in order to deal with VMs under both domains (due to the change in hostname -f behavior), don't worry -- adjusting an old VM to identify as part of .wikimedia.cloud only requires a simple change to /etc/hosts. I'll be available to make that change for any project that chooses consistency over backwards-compatibility.

[0] https://phabricator.wikimedia.org/phame/post/view/191/new_names_for_everyone

[1] https://phabricator.wikimedia.org/T260614

---

Wikimedia Cloud Services announce mailing list Cloud-announce@lists.wikimedia.org (formerly labs-announce@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud-announce _______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud

If I am currently using bastion-restricted.wmflabs.org in my ProxyCommand, am I also supposed to replace it? With bastion-restricted.wmcloud.org ? And is the distinction between regular bastion and restricted bastion still a thing?

On Tue, Sep 8, 2020 at 10:07 AM Andrew Bogott abogott@wikimedia.org wrote:

The modern name for that bastion is 'restricted.bastion.wmcloud.org'.

Ah, thanks! Updated my local config.

today's change did not affect public domains, only private .eqiad.wmflabs domain names. We have no plans to eliminate existing .wmflabs.org domain names because we don't want to break existing URLs.

ACK, thanks for not breaking URLs. It was also nice that removing a proxy in Horizon and adding a new one with wmcloud meant that old URLs don't break and they automatically redirect without the end user having to deal with it. Cool!

And is the distinction between regular bastion and restricted bastion still a thing?

It is, although I'm not 100% convinced that it has value.

Yea, me neither. But that's for another day maybe to bring up with the wider teams.