Page MenuHomePhabricator

Add support for managing wmcloud.org domain hosts in dynamic-proxy's domain proxy
Closed, ResolvedPublic

Description

See https://wikitech.wikimedia.org/wiki/Help:Using_a_web_proxy_to_reach_Cloud_VPS_servers_from_the_internet#Migrate_from_a_*.wmflabs.org_proxy_to_a_*.wmcloud.org_proxy for instructions on migrating!


"Shouldn't be hard!" -- famous last words

With the introduction of toolforge.org and use of the wmcloud.org domain by several projects which are managing their own LE certificates and DNS, folks are starting to ask about using *.wmcloud.org through the Horizon managed shared proxy system. We need a larger project to coordinate complete migration from *.wmflabs.org to *.wmcloud.org, but it would be reasonable to start allowing opt-in use of *.wmcloud.org via domain proxy.

There are really 2 use cases to consider here:

  1. Brand new services: An new service being created after the feature is available should just use its $NAME.wmcloud.org name with no $NAME.wmflabs.org equivalent.
    • Ideally it would not be possible to create a new legacy $NAME.wmflabs.org proxy at this point to reduce confusion for folks who find the system for the first time.
    • It should be possible to change the upstream target for an existing $NAME.wmflabs.org proxy at this time however, which is maybe a reason to implement T140391: Allow users to edit proxies first?
  2. Legacy services: A service that has previously used $NAME.wmflabs.org should be able to:
    • Setup $NAME.wmcloud.org as an alternate service name pointing to the same or different backend service for testing
    • Request that $NAME.wmflabs.org 308 redirect to $NAME.wmcloud.org at the front proxy once testing confirms that things are working under the new hostname
    • Once a redirect is setup, $NAME.wmflabs.org should continue to exist in DNS indefinitely to support "cool URLs don't change" functionality. Eventually these could move from pointing to domain proxy to pointing to a static proxy which only does $NAME.wmflabs.org -> $NAME.wmcloud.org 308 redirection

Event Timeline

bd808 renamed this task from support new domain in dynamic-proxy to Add support for managing wmcloud.org domain hosts in dynamic-proxy's domain proxy.Jun 24 2020, 6:01 PM
bd808 added a project: Horizon.
bd808 updated the task description. (Show Details)

From a UI perspective, here are the steps I'm imagining:

  1. Sometime soon: Extend the 'create a proxy' dialog to allow choosing a given proxy be in either .wmflabs.org or .wmcloud.org
  1. Sometime later: Add a new UI to create a redirect for an existing .wmflabs.org name (or possibly convert an existing one)
  1. Sometime even later: remove the option to create new proxies under .wmflabs.org

It was step #1 that I was asserting wouldn't be hard. If we feel strongly that we need to draw a line in the sand and prevent creation of new .wmflabs.org proxies sometime soon then this is more complicated since we need to support existing use cases while preventing introduction of new ones. (My feeling is that making .wmcloud.org the default domain in the creation UI is probably about as much prevention as we really need.)

Also -- is the purpose of supporting redirection so users only have to support one domain in their vhost? Or are there other reasons why it's important to have a redirect rather than just two different proxies to the same backend?

(My feeling is that making .wmcloud.org the default domain in the creation UI is probably about as much prevention as we really need.)

I think I would mostly agree with this POV. This is a much more deliberate choice than the way things are handled for Toolforge webservices which probably colors my view of the features needed.

Also -- is the purpose of supporting redirection so users only have to support one domain in their vhost? Or are there other reasons why it's important to have a redirect rather than just two different proxies to the same backend?

For me, it is about making it easier for folks to convert over. Not all backends are full featured Apache2 or Nginx instances, so doing the redirect on the backend side is not necessarily trivial. It is reasonably easy on the urlproxy side as soon as we have an indicator to tell us when to do it.

For me, it is about making it easier for folks to convert over. Not all backends are full featured Apache2 or Nginx instances, so doing the redirect on the backend side is not necessarily trivial. It is reasonably easy on the urlproxy side as soon as we have an indicator to tell us when to do it.

That makes sense. I was imagining that backend users would just have two vhosts (or better yet one vhost that matches both domains, but maybe that's not always easy)

Change 609581 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[openstack/horizon/wmf-proxy-dashboard@master] Introduce a new config structure, PROXY_DOMAIN_DICT

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

Change 609586 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] profile::wmcs::novaproxy: add use_wmflabs_root option

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

Change 609587 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] profile::wmcs::novaproxy: add acme_certname

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

Change 609609 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[labs/private@master] Added fake passwords for proxy_domain_passwords

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

Change 609610 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] Horizon: Include PROXY_DOMAIN_DICT

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

Change 609609 merged by Andrew Bogott:
[labs/private@master] Added fake passwords for proxy_zone_passwords

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

Change 609586 merged by Andrew Bogott:
[operations/puppet@production] profile::wmcs::novaproxy: add use_wmflabs_root option

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

Change 609587 merged by Andrew Bogott:
[operations/puppet@production] profile::wmcs::novaproxy: add acme_certname

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

Change 609790 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] dynamic proxy: don't treat "" as a boolean for $acme_certname

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

Change 609790 merged by Andrew Bogott:
[operations/puppet@production] dynamic proxy: don't treat "" as a boolean for $acme_certname

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

Change 609610 merged by Andrew Bogott:
[operations/puppet@production] Horizon: Include PROXY_DOMAIN_DICT

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

Change 609804 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] Horizon: Set default domain for proxy UI

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

Change 609581 merged by Andrew Bogott:
[openstack/horizon/wmf-proxy-dashboard@master] Introduce a new config structure, PROXY_ZONE_DICT

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

Change 609825 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[openstack/horizon/wmf-proxy-dashboard@train] Introduce a new config structure, PROXY_ZONE_DICT

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

Change 609825 merged by Andrew Bogott:
[openstack/horizon/wmf-proxy-dashboard@train] Introduce a new config structure, PROXY_ZONE_DICT

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

Change 609826 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[openstack/horizon/deploy@train] Update wmf-proxy-dashboard submodule

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

Change 609804 merged by Andrew Bogott:
[operations/puppet@production] Horizon: Set default domain for proxy UI

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

Change 609826 merged by Andrew Bogott:
[openstack/horizon/deploy@train] Update wmf-proxy-dashboard submodule

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

For now I've implemented a simple solution: users can now create new proxies under .wmflabs.org or under .wmcloud.org. The default suggested domain is wmcloud.org.

That should unblock new projects. Removing the ability to create new .wmflabs.org remains to be done (and, as Bryan mentioned, probably requires some way to edit existing .wmflabs.org proxies).

Change 612442 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] wmcs domain proxy: add a fallthrough redirect for unknown .wmflabs.org domains

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

Change 612442 merged by Andrew Bogott:
[operations/puppet@production] wmcs domain proxy: add a fallthrough redirect for unknown .wmflabs.org domains

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

Change 612455 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] wmcs domain proxy: change escaping in lua regexps

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

Change 612455 merged by Andrew Bogott:
[operations/puppet@production] wmcs domain proxy: change escaping in lua regexps

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

I've put in place a fallthrough redirect and a wildcard *.wmflabs.org domain so now any <name>.wmflabs.org domain that is not otherwise defined will automatically redirect to <name>.wmcloud.org.

I've also set the ttl for .wmflabs.org to 5 minutes. That might not actually have been necessary but I ran into some weird negative-cache issues when testing.

A user's process for updating their domain should be:

  • create a new .wmcloud.org proxy
  • delete the old .wmflabs.org proxy

This feels sort of weird and unintuitive but it has a few advantages: the user process is really easy; we don't need to maintain state about specific .wmflabs.org domains anywhere; it was easy to implement.

This feels sort of weird and unintuitive but it has a few advantages: the user process is really easy; we don't need to maintain state about specific .wmflabs.org domains anywhere; it was easy to implement.

I agree that it's weird (e.g. https://askdjfhsdkjfh.wmflabs.org/ will try to redirect) but this process is so straightforward it's going to make migrating really simple. Thank you!