Arvados

20688-redirect-urldecode @ arvados-workbench2|84161e969c13b42451752bd5f134b968d15c1001

Workbench 2 URL-decoding fix that came up in trying to rewrite URLs.

developer-tests-workbench2: #1244

I think it would be nice to have tests for this fix.

20688-redirect-urldecode @ arvados-workbench2|756e585f2c1c50ed550d88c7becfe757dd9d8401

Adjusted the redirectTo unit test to include URI quoting

developer-tests-workbench2: #1247

This LGTM, thanks!

20688-wb1-to-wb2-redirects @ 929825efa55429c7a7c9c9bf76d3a71f94e9d0ce

• arvbox uses wb2 by default
• used arvbox to prototype the rewrite patterns from wb1 to wb2 paths
• added redirects to salt but need to test it

20688-wb1-to-wb2-redirects @ b48f7d783d1d865a259282f3177cbd7e17731254

• Reworked so that "workbench.domain" serves wb2 and "workbench2.domain" is a redirect
• arvados-formula probably needs some maintenance

20688-wb1-to-wb2-redirects @ ef2644287f25a95b510c4532822f92b3ecd7e33a

Rebased on 20680-default-config-updates and 20610-installer-load-balancer to address any merge conflicts.

Haven't manually tested, but LGTM.
One question, though: If we're setting up the redirects on the installer code, could we also remove wb1 installation altogether?

Lucas Di Pentima wrote in #note-18:

Haven't manually tested, but LGTM.
One question, though: If we're setting up the redirects on the installer code, could we also remove wb1 installation altogether?

I could be wrong about this (I probably am), but my assumption was that the "workbench" role in arvados-formula is responsible for both installing the package and fetching the "workbench.domain" certificate and so without updating the formula, if we don't install the workbench role somewhere we don't have the certificate.

But now I am looking at it closer, and I see there's "letsencrypt_workbench_configuration.sls" and "letsencrypt_workbench2_configuration.sls", so maybe it ought to just be doing something like this?

### LETSENCRYPT
letsencrypt:
  domainsets:
    workbench.__DOMAIN__:
      - workbench.__DOMAIN__
    workbench2.__DOMAIN__:
      - workbench2.__DOMAIN__

Or maybe there's is an even better way to do this so there's just one certificate for both workbench.domain and workbench2.domain? (One issue I ran into was that the workbench.domain can't use the workbench2.domain certificate). Can we do this?

### LETSENCRYPT
letsencrypt:
  domainsets:
    workbench.__DOMAIN__:
      - workbench.__DOMAIN__
      - workbench2.__DOMAIN__

Peter Amstutz wrote in #note-19:

I could be wrong about this (I probably am), but my assumption was that the "workbench" role in arvados-formula is responsible for both installing the package and fetching the "workbench.domain" certificate and so without updating the formula, if we don't install the workbench role somewhere we don't have the certificate.

AFAICT, arvados-formula has modules for wb1 and wb2 separately (see: https://github.com/arvados/arvados-formula/tree/main/arvados) and in provision.sh line 901 you can see that we're adding the corresponding states for the different workbench and workbench2 roles, so I would say it's possible to do. Nginx & LE configs are treated separately from the formula (with installer's custom pillars) so those could be kept while avoiding installing wb1.

But now I am looking at it closer, and I see there's "letsencrypt_workbench_configuration.sls" and "letsencrypt_workbench2_configuration.sls", so maybe it ought to just be doing something like this?
[...]
Or maybe there's is an even better way to do this so there's just one certificate for both workbench.domain and workbench2.domain? (One issue I ran into was that the workbench.domain can't use the workbench2.domain certificate). Can we do this?

I would have to do some testing, but I think it should be doable. OTOH, this might not be so trivial, so maybe we can write a new story for it?