Pegasus: remove various subdomain sites #22865
Conversation
| 'sg.code.org' => 'code.org', | ||
| 'tr.code.org' => 'robincode.org', | ||
| 'uk.code.org' => 'code.org', | ||
| 'za.code.org' => 'codeforchange.co.za/', |
There was a problem hiding this comment.
@wjordan Is this the right place to do such redirects?
If so, what's the best way to test that this works?
And is it safe to include the removal of these sites from pegasus in this PR as well?
There was a problem hiding this comment.
I haven't touched or looked at any of this code since 2015 so I can't answer any of your questions confidently, but I'll give my best guesses.
-
I think this is an OK place to do redirects
-
Test manually after merging the attribute changes- this feature was never developed in a way that could be tested in an isolated environment. Note that a redirect for
ar.code.orgwon't also provide a redirect forstaging-ar.code.orghere, so you'll need to include those if you want to test on staging, otherwise just test once it's pushed to production. -
Removing the subdomains from
CDO.partnerswill remove them from the CloudFront distribution, which will cause those requests to fail unless you manually update the DNS entries first to send requests directly to the load balancer instead of through the CloudFront distribution. Each partner has the following manual DNS entries: -
staging-za.code.org:ALIAS staging.code.org. -
test-za.code.org:ALIAS test.code.org. -
za.code.org:ALIAS code.org. -
localhost.za.code.org:ALIAS localhost.code.org.
I'd suggest deleting all but the production one, which should have its alias updated to point to the production-codeorg load balancer.
Beyond that, I can't think of anything else that will definitely break from removing the partner sites in this PR, but I can't guarantee safety beyond whatever our tests currently cover.
This extracts some minimal logic from #22865 to redirect ar.code.org to an external site. By removing it from the list of partner sites, the subdomain will be removed from the CloudFront distribution. Before deploying, I will update the DNS entry for ar.code.org to send requests directly to our load balancer instead of CloudFront. Then the redirect provided via chef to varnish will operate successfully after this change is deployed to production.
|
CC @davidsbailey - great news for pegasus / content pipeline! |
|
|
Conflicts: cookbooks/cdo-varnish/attributes/default.rb deployment.rb
|
Folks, now that #22865 is working on production (see https://ar.code.org), this PR is ready for final review. |
| assert_equal 'https://uk.code.org/about', url_converter.replace_origin('https://uk.code.org/about') | ||
| assert_equal 'https://ro.code.org', url_converter.replace_origin('https://ro.code.org') | ||
| assert_equal 'https://ro.code.org/about', url_converter.replace_origin('https://ro.code.org/about') | ||
| assert_equal 'https://advocacy.code.org', url_converter.replace_origin('https://advocacy.code.org') |
There was a problem hiding this comment.
this change seems unrelated to this PR?
There was a problem hiding this comment.
Given that we were losing tests on uk.code.org and ro.code.org I wanted to add a couple additional tests on a subdomain that remained, advocacy.code.org.
A variety of subdomains on http://code.org are removed, and now redirect to other sites, as shown in this table: