Change dev domain: `local.edly.io` -> `local.openedx.org`

[kdmccormick]

Background

Tutor requires a dev domain (other than localhost) which points to 127.0.0.1. I'm fuzzy on the reasons but I'm pretty sure it has to do with how authn plays with Docker's network addresses.

Historically this has been local.overhang.io, as of Quince it's local.edly.io.

Some options:

• related to Open edX (would mean we need to get 2U's approval):
  • local.openedx.org
  • dev.openedx.org
  • my.openedx.org
• related to Tutor (would mean that this domain wouldn't be used for non-Tutor dev envs):
  • tutorlocal.site
• related to e-learning:
  • localdev.academy
  • localdev.school
• related to nothing in particular:
  • bananasystems.com

Note that .dev isn't an option (I think) because it is an https-only domain.

@regisb indicated he'd be on board with this.

Tasks

• [ ] choose a domain
• [ ] set up the domain (Axim)
• [ ] point Tutor at the new domain
  • [ ] optional: backport this to the previous release's Tutor version so that the old release's dev continues to work even after local.overhang.io is shut down.
• [ ] make sure this is added to the release notes

Target

Quince

[regisb]

Tutor requires a dev domain (other than localhost) which points to 127.0.0.1. I'm fuzzy on the reasons but I'm pretty sure it has to do with how authn plays with Docker's network addresses.

Kind of :) There are actually a couple of reasons for having our own domain names, but only one which really matters. Services often need to talk to each other, and for that they use the same hostnames whether they make calls on the internal network or on the internet. For instance, the CMS makes HTTP requests to the LMS via http://local.overhang.io both in the Python process and the browser client. We could replace "local.overhang.io" by "openedx.localhost", which would also resolve to 127.0.0.1, but then we would have to tell the cms container that "openedx.localhost" is actually the "lms" container. And I don't really know how to do that.

[kdmccormick]

Makes sense!

[kdmccormick]

Some things that Axim just discussed:

• 2U owns the Open edX trademark, so I'll need to check with them on this.
• We don't want operators to put openedx in their real prod instance's domain. Hopefully this wouldn't encourage that.
• An alternative that @brian-smith-tcril suggested: use something tutor-specific, like http://tutor.dev (turns out that's taken, but you get the idea).
• Another alternative, @feanil suggested doing something nonsense like http://bananasystems.com because it doesn't really matter what the domain is as long as the user can remember it.
  • I disagree with this, I think the most memorable domain is one that relates to the project, and I think that having something openedx-related or tutor-related lends an air of professionalism.

[kdmccormick]

One point in favor of something openedx-specfic rather than tutor-specific is that the same domain could be used in settings files for any Open edX distribution. Theoretically, Tutor and Devstack could both point to local.openedx.org.

[kdmccormick]

Trying to make this happen has been so much bureaucracy. I'm not sure I care enough to make it happen any more. local.edly.io is short and sweet, and nobody in the Open edX community is complaining about it right now.

@regisb , if you would like to move to another domain, let me know. Otherwise, I'm fine closing this and sticking with local.edly.io 😄