Migration checklist

[bridgetkromhout]

What we have to do, and when.

Preparation

• heads-up to core org team
• establish a timeline: Create communication with migration information #96 (comment)
• send communication with timeline and link to organizers: Create communication with migration information #96
• add exact replicas of current events' 2016 sites to new repo (this is the main place you can help!): migration for 2016 events #107
• Migrate 2015 and previous: Migrate events from 2015 and before #29
  • Pick & announce date for freeze on merges to webby content 2015 and before: Determine cut-off for read-only sites #95
• [ ] Dump webby one last time & migrate as html
• determine how/if we'll test changes in a shared staging env after cutover
• add needed maintainers to org
• crawl for broken links
• Set date with Patrick for DNS cutover

Cutover time

• Verify that test site looks good
• Patrick to make DNS change to github pages
  • Cloudflare right away? for future SSL?

After cutover

• crawl for broken links
• send communication reminding everyone where to submit PRs now

[mattstratton]

Should you add a step for "post-cutover" to lock down the old repo/remove committers? I suppose if all the committers to the old repo have given a thumbs up that they KNOW to not accept pr's on it, that's fine too.

[bridgetkromhout]

Should you add a step for "post-cutover" to lock down the old repo/remove committers? I suppose if all the committers to the old repo have given a thumbs up that they KNOW to not accept pr's on it, that's fine too.

That will be up to Patrick since he controls the old repo (it's in his personal account and he is thus the only one who can add/remove committers).

Presumably once it controls nothing, PRs to it will just be a no-op.

[jedi4ever]

@bridgetkromhout @mattstratton if you can say how to generate the new static site I can add the build circle.yml to upload it to s3 & map it to the devopsdays.org route53 record

[mattstratton]

@jedi4ever I'm slightly leery about changing the build system off of wercker and gh pages, as it's completely working now. Given the timeframe we are working on, changing the build plumbing on the app makes me nervous. All that is needed for the cutover is cnaming the devopsdays.org route53 record to devopsdays.github.io (when we are ready to go, that is).

[mattstratton]

in theory it should be pretty straightforward though, but since I'll be moving fast with changes and I want to be able to see exactly when they change, etc, during the next couple weeks, i'm nervous about losing that insight.

[jedi4ever]

root records of dns can not be CNAME's - one of the limitations so it would only work with www.devopsdays.org and not devopsdays.org - building it on werker & gh pages is fine . I'll add the push to s3->bucket don't worry. I just need some wercker access to add some private keys

[bridgetkromhout]

Hi, @jedi4ever - @mattstratton can set you up with any access you need.

I'd like to serve the devopsdays.org site from github pages and build with wercker because it's much easier to federate/distribute access with that. I don't want to involve S3 at all.

I use github pages with bridgetkromhout.com on github pages no problem. Github provides IPs to use for that.

Thanks!

[mattstratton]

@jedi4ever I do this today with www.arresteddevops.com and arresteddevops.com pointing to gh pages. It works fine. I know that technically the RFC says you cannot cname a root record, but every provider does it and it works fine for everyone. :)

[jedi4ever]

got it @bridgetkromhout - E-TOO-OLD-GITHUB-KNOWLEDGE
this is the new way -https://help.github.com/articles/setting-up-an-apex-domain/
let me know when you want/need to switch

[mattstratton]

(basically, it works because cloudflare does cname flattering) https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root

[mattstratton]

Either way, bikeshed accomplished! Thanks for digging that up!

[jedi4ever]

I've rechecked the config

technically devopsdays.org -> redirects to www.devopsdays.org
and www.devopsdays.org -> fastly -> s3 bucket.

don't think you can browser cache on github pages , let me know if you'd like to use fastly as a CDN

www.devopsdays.org.     289     IN      CNAME   www.devopsdays.org.global.prod.fastly.net.
www.devopsdays.org.global.prod.fastly.net. 19 IN CNAME global-ssl.fastly.net.
global-ssl.fastly.net.  19      IN      CNAME   fallback.global-ssl.fastly.net.
fallback.global-ssl.fastly.net. 19 IN   A       23.235.43.249

[mattstratton]

Yeah, I handle all my speeding up stuff via cloudlflare (injecting browser caching, cdn, etc) so i guess you would just need to reconfigure fastly to point to the gh pages as it's origin. That should work okay since you just have to make sure that GH pages knows the x-orginally-to header for it to serve.

[bridgetkromhout]

We didn't really end up following this checklist. Here's what happened:

@mattstratton and I looked at fastly. I set up a new config and pushed it out, but we couldn't have the hugo settings set to the same hostname that fastly was coming in looking for. Instead of renaming the origin server, we decided we just didn't need to be using fastly anyhow.

Patrick gave us AWS keys. Here's how I changed the cname to point to github pages:

$ cat change-to-github-devopsdays.json
{
  "Comment": "Using github pages",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.devopsdays.org.",
        "Type": "CNAME",
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "devopsdays.github.io"
          }
        ]
      }
    }
  ]
}
Bridgets-MacBook-Air:~ bridget$

$ aws route53 change-resource-record-sets --hosted-zone-id Z3G7FSH16FD4KP --profile=devopsdays --change-batch file://change-to-github-devopsdays.json
{
    "ChangeInfo": {
        "Status": "PENDING", 
        "Comment": "Using github pages", 
        "SubmittedAt": "2016-05-07T16:28:09.485Z", 
        "Id": "/change/C2JL0Z5PDHTVX"
    }
}
Bridgets-MacBook-Air:~ bridget$

$ aws route53 get-change --id C2JL0Z5PDHTVX --profile=devopsdays
{
    "ChangeInfo": {
        "Status": "PENDING", 
        "Comment": "Using github pages", 
        "SubmittedAt": "2016-05-07T16:28:09.485Z", 
        "Id": "/change/C2JL0Z5PDHTVX"
    }
}
Bridgets-MacBook-Air:~ bridget$

$ aws route53 get-change --id C2JL0Z5PDHTVX --profile=devopsdays
{
    "ChangeInfo": {
        "Status": "INSYNC", 
        "Comment": "Using github pages", 
        "SubmittedAt": "2016-05-07T16:28:09.485Z", 
        "Id": "/change/C2JL0Z5PDHTVX"
    }
}
Bridgets-MacBook-Air:~ bridget$

Once the DNS change was in place, we merged #280 too, and the site works.

To do:

The apex is still set to S3, and the TTL is still at 60 seconds.

[mattstratton]

The downside of taking out fastly is that the browser caching is not very aggressive when set by GH pages. Cloudflare handles this all magically and having done both now (trying to make this work with Fastly vs doing a hugo + ghpages + cloudflare) I think that cloudflare ends up doing this a lot more simply.

At some point in the near future we should move DNS off of route 53 onto cloudflare, which would have DNS services on cloudflare as well as reverse proxy (side benefit is free SSL which makes us look fancy and "with it").

[jedi4ever]

the fastly would be an easy fix - it had a default host configure www.devopsdays.org , making this devopsdays.github.io should do the trick. It's the default http.header it sends to backends configured.

But as there a willing to go for cloudflare and you willing to own it , I'm not stopping ya @mattstratton :)

[mattstratton]

@bridgetkromhout - i think this issue can be closed?