(In reply to comment #0)

Every time I need to access the evermoving triple-subdomain-crossword
http://deployment.wikimedia.beta.wmflabs.org and so on, I get headache.

In that case beta.wmflabs.org would be sufficient.

(In reply to comment #0)

As a first step, I'd like a special page on Wikitech, an HTML or txt file
updated by a script in whatever place, *something* to list all configured
*.wmflabs.org domains

All domains are available in the database afaik (as they are created and given IP addresses from the wiki).

However things like http://fr.wikipedia.beta.wmflabs.org/ won't be listed as that domain isn't "created". The registry has *.beta.wmflabs.org and beta.wmflabs.org.

FWIW, I've set up https://wikitech.wikimedia.org/wiki/Labs in such a way that it'd be a viable landing page to redirect people to from https://wmflabs.org . Not a great landing page, mind you, but a reasonable first stop.

Awesome. Thanks Rob!

So it'd essentially just be a dump of Designate's data for the wmflabs.org DNS zone?

For the beta cluster the Rosetta stone is http://deployment.wikimedia.beta.wmflabs.org/wiki/Special:SiteMatrix which you can also get to as http://beta.wmflabs.org/wiki/Special:SiteMatrix.

We have an effectively manually-updated, maybe-one-off page showing these domains here: https://wikitech.wikimedia.org/wiki/Purge_2016
It was generated using https://github.com/wikimedia/operations-puppet/blob/production/modules/openstack/files/novastats/novastats.py and P3358 which are sort of hacked together scripts that I'd rewrite if we were going to do this task properly.
(requires access to a host like silver.wikimedia.org or labcontrol1001.wikimedia.org and the novaadmin pass in a file named novaadmin_pass)

Yes, something like that, made into a sortable table with clickable links and regularly updated.

Maybe we could just make a cron that updates a wikitech page, or leaves a text file accessible under wikitech.wikimedia.org or something.

https://wmflabs.org now redirects to https://wikitech.wikimedia.org/wiki/Portal:Wikimedia_Labs which is a good starting point.

For Tool Labs, https://tools.wmflabs.org/ points to:

• https://tools.wmflabs.org/?list, which contains an complete (but not so user-friendly) overview
• and https://tools.wmflabs.org/hay/directory/ which is a lot more useful, but not definitively complete.

For Wikimedia Labs as a whole, the definitive list of projects is available through OpenStack, best browsed via https://tools.wmflabs.org/openstack-browser/, which is already linked to from the https://wmflabs.org portal.

One thing we could do is add a view to https://tools.wmflabs.org/openstack-browser/ that lists the known subdomains registered with the labs web proxy.

In T45580#3192731, @Krinkle wrote:

One thing we could do is add a view to https://tools.wmflabs.org/openstack-browser/ that lists the known subdomains registered with the labs web proxy.

See also: T115752: invisible-unicorn (dynamicproxy) should provide an easy way to see where a host routes without knowing the project

This page is just a proof of concept (not live-updating) but is this the kind of thing we're talking about?

https://wikitech.wikimedia.org/wiki/Nova_Resource:Testlabs/testpage

In T45580#3195464, @Andrew wrote:

This page is just a proof of concept (not live-updating) but is this the kind of thing we're talking about?

https://wikitech.wikimedia.org/wiki/Nova_Resource:Testlabs/testpage

Yes. That's at least the data we would like to surface. The UX there may leave a bit to be desired, but I guess it is ⌃+F friendly.

I figured a big dump that users can search is better than a search widget since it's not that much data -- but, y'know, either way.

I can make a cron that runs on labcontrol and updates that page periodically, or I can dump my code here and someone else can write a tool to drag this info up on demand.

Mentioned in SAL (#wikimedia-labs) [2017-04-21T00:10:55Z] <bd808> Deployed c491ace to display proxy information on project pages. T45580

Change 349531 had a related patch set uploaded (by Andrew Bogott):
[operations/puppet@production] Designate: Allow labs clients to access the designate API.

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

The result of bd808's work is https://tools.wmflabs.org/openstack-browser/proxy/

Thanks. That's quite useful.

Change 349531 merged by Andrew Bogott:
[operations/puppet@production] Designate: Allow labs clients to access the designate API.

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