Hi there! Is there a list of feature flags somewhere to be used inside sentry.conf.py? It was awfully hard to enable relays for on-prem since I had to figure out what the corresponding feature flag is, and I started to wonder if there is a list somewhere with all the flags…
Relays for onprem, and other features not enabled by default, are not stable, and particularly we do not guarantee smooth operation outside of SaaS. As such it would not make sense to document how to enable those unstable features. A lot of the unstable features are generally undocumented.
Once relay is stable we will enable it for onprem as well.
1 Like
If it’s not stable onprem then why is the onprem repository already set up to use relay, except it doesn’t properly work without the flag…?
There are external relays acting as proxies and relay as an internal component to sentry. As opposed to the former, the latter is stable, enabled by default and should work. If you can send events into onpremise any way at all it works.
The onprem repo is set up to use nginx to forward requests from /api/store and /api/{number} to relay so I believe it’s an internal component. It’s also configured by default to use managed mode which won’t work without the relay feature…
Relevant bit of code on getsentry/onpremise:master: https://github.com/getsentry/onpremise/blob/1c9bfd90174c02e98186c830582bcea5048fbfda/nginx/nginx.conf#L63
Which is honestly strange if relay as a component is not meant to be stable yet…
Again, internal relays are special cased. We recently touched this logic so there may have been a regression of some sort. If you believe there is a bug please file it against the onpremise repo.
@kanadaj - Whatever is necessary for Relay to work on on-premise is already set up and we have verified that it works. If it doesn’t, I recommend filing an issue on the repo with as much details as possible. Mind you that we have merged a few fixes related to this (none of them include feature flags though) and now there’s a test, ensuring Relay works as expected:
If you are still having issues with the latest master, please file an issue as recommended.
Regarding your original question around documenting feature flags:
We have thought about this and were planning to do this but then decided to turn on all features that are mature enough by default so we don’t need to document this. This is better as it is a challenge to keep this documentation up to date and it also makes the installation process unnecessarily complex.
Happy to hear your thoughts on this approach.
Correct me if I’m wrong, but Relay’s default mode is “managed” (unless explicitly set to “proxy” or “static”), which needs to authenticate with Sentry Web, which in turn needs the Relay feature flag to add the Relay public key to Sentry for the authentication to work. At least that’s my understanding of it. Just trying to comprehend this before making a ticket on GitHub, I wouldn’t want to fill your issue tracker with nonsense 
As for the flags, wouldn’t it make it faster and safer to document feature flags so a smaller subset of on-premise users can use it and report any arising issues before the features are released to everyone? In fact, since the flags are fairly self-evident due to the naming, would it not be possible to just make a crawler that updates a readme file with the list of flags in the source code?
You are correct until the feature flag part. The thing is, I keep saying we have a working CI test on top of manual tests we have done locally to ensure Relay works as if it doesn’t, then none of the event ingestion works, and you seem to be ignoring that and assuming we keep shipping something broken.
Here is where Relay was first introduced:
Note the code around PK generation and then adding this to the sentry.conf.py in the install.sh file.
This is where we fixed an issue related to writing these credentials:
This is where we removed the need for registered PKs as Relays are already in the private network and rely on this instead:
You can see all other Relay-related PRs here: Pull requests · getsentry/self-hosted · GitHub
The crawler/automation part is not very applicable as some flags need extra infrastructure or migrations which are not necessarily available to the on-premise repo as they get added. We do controlled releases for alpha features with consulting to our product team when we need the OSS community’s feedback (instead of relying on the testing on sentry.io).
That said, if you really want to do such a thing or see all the feature flags, I think this file is what you are looking for:
I’d be interested to see a prototype of the crawler idea you propose but cannot promise that we’d adopt it as this would need the blessing of our product team too 
Ah I didn’t realise you were hard-coding the PK into the config file via install.sh. My apologies! I’m running Sentry in Kubernetes and so the install.sh file is never ran as it is and while I have integrated a previous version into my config, this change eluded me. This resolved much of my confusion.
That said, so far Relay is working for me via the flag, so there is that
That is exactly what I was looking for! I just couldn’t manage to find it… Thank you!
1 Like
Not sure which flag are you referring to but if it’s the relay open registration flag, I strongly recommend turning that off for security reasons. Have a look at this patch I shared above instead: ref(relay): Remove PK and rely on INTERNAL_IPS by BYK · Pull Request #572 · getsentry/self-hosted · GitHub
This removes the need to bake the PKs into the config file and simply define an internal network IP range and accept any relays coming from that network. Note that it has a follow up that removes the assignment to INTERNAL_IPS: fix(superuser): Don't set INTERNAL_IPS to Docker network by BYK · Pull Request #581 · getsentry/self-hosted · GitHub
That is exactly what I was looking for! I just couldn’t manage to find it… Thank you!
Glad it was useful!