Rename onpremise to self-hosted

[chadwhitacre]

In the docs we're using "self-hosted" to name what we're doing here. For branding purposes I would like to standardize on that and stop referring to "onpremise."

(Short URL, fwiw: https://git.io/JSDlX)

Todo

• rename repo
• code
  • easy
    • sentry.io—archived repo
    • sentry-release—moribund repo, don't care
    • getsentry/labels@9d35acc
    • getsentry/deps@5962f6b
    • https://github.com/getsentry/demo/pull/11
    • Rename onpremise to self-hosted develop#469
    • Rename onpremise to self-hosted eng-pipes#273
    • https://github.com/getsentry/etl/pull/671
    • https://github.com/getsentry/lookml/pull/318
    • Rename onpremise to self-hosted publish#670
    • Rename onpremise to self-hosted relay#1136
    • Rename onpremise to self-hosted #1169
    • sentry
      • Start renaming onpremise to self-hosted sentry#30482
      • Continue self-hosted rename in build-related files sentry#30483
      • Remove RemoteNewsletter (unused for 4 years) sentry#30486
    • Rename onpremise to self-hosted sentry-dart#642
    • Rename onpremise to self-hosted sentry-docs#4437
    • Rename onpremise to self-hosted snuba#2240
    • https://github.com/getsentry/static-sites/pull/773
  • hard
    • backend
      • https://github.com/getsentry/getsentry/pull/6841
      • https://github.com/getsentry/single-tenant/pull/429
      • Switch from ONPREMISE to SELF_HOSTED on backend sentry#30973
      • Comment sweep for onprem → self-hosted sentry#31066
    • frontend
      • add isSelfHosted in sentry (done in #30973)
      • Flip to isSelfHosted on the frontend sentry#31065
    • trust it
      • https://github.com/getsentry/getsentry/pull/6866
      • remove SENTRY_ONPREMISE in single-tenant
        • punting for "months" ... documented in https://github.com/getsentry/single-tenant/pull/432
        • https://github.com/getsentry/getsentry/pull/10950
    • remove SENTRY_ONPREMISE and isOnPremise in sentry (kill backcompat) – do this, like, waaaaay later
• forums—Deprecate forum in favor of GitHub Issues #1151
• blog—Rename onpremise to self-hosted #796 (comment)
• Repair triage stats post-rename eng-pipes#274
• Audit to make sure monthly CalVer release will work.

[BYK]

I'm not sure if the effort is worth the benefits.

[chadwhitacre]

GitHub handles renames gracefully. The one lingering question I've had is forks, but it seems from testing (not seeing docs) that there's no issue with a fork of a renamed repo. The fork keeps the old name, and its connection to the renamed parent. If anyone with a fork has the upstream set as a remote, GitHub redirection/aliasing ensures that they are unaffected—as long as we never break the redirect by creating a new onpremise repo.

tl;dr I think the effort is trivial.

Fork Test

[BYK]

Alright, you know what, let's try this :)

[chadwhitacre]

@ingria Do you foresee problems with this? Why are you 😕?

[ingria]

Technically - no, not at all. I just didn't understand what the benefits of renaming would be. That's why I was a little 😕

Anyway, there are also some other places that might need to be edited:

• Help articles (example)
• Community forums
• Blog articles (example)

[chadwhitacre]

benefits

Less confusion. Right now we use two names—"on-premise," "self-hosted"—for the same thing. May not be worth it. Need to stew on this some more ... 🤔

[chadwhitacre]

The more I think about it, the more I don't like either name—onpremise or self-hosted—for this repo. I think a better name would be single-node, because it better captures our intention here: to package up all of Sentry for deployment on a single node, in order to support a) proofs of concept for people evaluating SaaS, and b) small deployments for students, hobbyists, and small orgs. "Self-hosted" is broader as it really encompasses multi-node setups, too, which we don't officially support and never will (SaaS! SaaS!). Moreover, work that is relevant to self-hosters of any scale quite often (almost always?) impacts our other "primary" repos, e.g. #863 and #857 should really be against sentry, imo. We have a label in that repo to flag issues of particular (exclusive?) relevance to self-hosters.

[ingria]

This name may better reflect how it's supposed to work, but it doesn't describe what is this project for.

I mean, imagine you've just heard about some cool project called Gentry. And you'd like to know whether it's possible to use it on your own servers. How would you google it: "gentry self hosted" or "gentry single node"?

In other words, "single-node" is ok for a repo name, but not ok for a product name. Just my opinion, of course.

[BYK]

I agree with @ingria here, this was my main concern too. How about something like self-hosted-core or something as this setup can be expanded into a multi-node setup through Docker Swarm or something like https://kompose.io/. Also AFAIK https://github.com/sentry-kubernetes/charts/ is tracking this repo for updates.

[chadwhitacre]

Returning to the original idea here, renaming to self-hosted.

[chadwhitacre]

I ran this by the Backend TSC and nobody raised any red flags from a technical standpoint, experience with repo renames is that GitHub does a great job making it seamless. All clear from that standpoint!

[chadwhitacre]

Help articles (example)

Looks like we 404'd that particular article (I remember doing this a month or so ago but I don't remember exactly what it was), I guess that was the only one.

Community forums

I just started a thread in the forums to see if anyone is paying attention there. Where I want to take that conversation is I actually want to deprecate the forum in favor of GitHub Issues. 🐭

Blog articles (example)

I do find references to on-premise historically on the blog, looks like June, 2020 is the latest? Not all of the references

[chadwhitacre]

I added a todo to this ticket. I'm going to let this forum meta post sit for a day or two, if it's 🦗 s then I intend to proceed with this ticket. If it's not then we'll talk first. :)

[chadwhitacre]

I'm planning to rename the repo next week during the US Thanksgiving lull.

[chadwhitacre]

Repo is done: https://github.com/getsentry/self-hosted. 💃

[chadwhitacre]

After reviewing the blog posts for mentions of "on-premise," I don't think we need to go back through and change those. There are 11 mentions but one is in reference to a different product. Of the 10 posts that talk about on-premise Sentry, three also refer to it as "open source" Sentry, which is definitely something we are moving away from—SaaS is open-source too, there's no feature difference between SaaS, single-tenant, and self-hosted. All that said, historically we did use "on-premise" and "open-source" to refer to the product now called "self-hosted Sentry," and I don't think we need to rewrite history. Being consistent in the future is enough.

1. https://blog.sentry.io/2020/06/22/self-hosted-sentry-switching-to-calver (1)
2. https://blog.sentry.io/2020/01/07/self-hosted-sentry-10-is-ready-to-serve-get-it-while-its-hot (1)
3. https://blog.sentry.io/2019/03/14/nextcloud-uses-sentry-to-build-federated-clouds (1) — this one refers to Nextcloud, not Sentry
4. https://blog.sentry.io/2019/02/14/sentry-thrives-open-source-software-company (3 + "open source")
5. https://blog.sentry.io/2016/07/05/releasing-sentry (4 + "open source")
6. https://blog.sentry.io/2016/01/12/monitoring-the-monitor (8)
7. https://blog.sentry.io/2015/12/29/sentry-js-sdk-release (1)
8. https://blog.sentry.io/2015/10/08/sentry-8-is-here (8)
9. https://blog.sentry.io/2015/09/29/sso-for-all (8)
10. https://blog.sentry.io/2015/08/04/rethinking-sentrys-documentation (3 + "open source")
11. https://blog.sentry.io/2015/06/30/driven-by-open-source (1)

[chadwhitacre]

I made PRs for the rest of the repos except for sentry and getsentry. Those will take some more thought as what is at issue is a configuration change and we need to do handle that in a graceful way.

[chadwhitacre]

Audit to make sure monthly CalVer release will work.

I got nervous when I noticed that the publish repo looks at the issue title, but we should be fine because the issue title comes from the repo slug. 👍

[chadwhitacre]

@ayozemr @fliespl et al. Now that #1169 has landed would someone be able to upgrade to the latest master and report back if you encounter any issues? I'd love to beta-test this a bit before the next monthly release. 🙏

[chadwhitacre]

Wrong approach, need to revisit: getsentry/sentry#30556 (comment).

[chadwhitacre]

(Inlining ...)

The better way to do this is to:

1. Set SENTRY_SELF_HOSTED in the downstream apps (getsentry and single-tenant) as a no-op duplicate. It sits right next to SENTRY_ONPREMISE but nothing reads it.
2. Modify the upstream (i.e., sentry, here) to use/read SENTRY_SELF_HOSTED on the backend (basically this here PR here).
3. Remove SENTRY_ONPREMISE from the downstreams.
4. Modify the upstream to set isSelfHosted as a no-op duplicate on the frontend.
5. Modify the downstreams to read from isSelfHosted.
6. Modify the upstream to read from isSelfHosted and remove isOnPremise.

The crux is that downstreams set the backend SENTRY_FOO but consume the frontend isFooBar, while upstreams consume the backend and set the frontend. The right approach looks like this:

backend  add    downstream
backend  add    upstream
backend  remove upstream
backend  remove downstream

frontend add    upstream
frontend add    downstream
frontend remove downstream
frontend remove upstream

[chadwhitacre]

Surfaced in review with Backend TSC:

• don't remove ONPREMISE from sentry (upstream) until after removed from downstream
• check on single-tenant flow, account for need to cut a release

[chadwhitacre]

Big config changes shipped to SaaS prod. A couple more bits to flip in the coming weeks/months and then removing backcompat "at some point."

[chadwhitacre]

Flipped the bit on getsentry, punting indefinitely on single-tenant. Gonna declare victory here.

Rename: check! 💃