[Rls] de-experimentalize RLS in XDS #33290
Conversation
grpc-checks
bot
added
per-call-memory/neutral
per-channel-memory/neutral
bloat/none
labels
apolcyn
changed the title
apolcyn
changed the title
There was a problem hiding this comment.
In C-core, we normally just remove the env var guard once interop tests pass rather than just flipping the default, so that we don't have to remember to come back later and remove the env var guard completely.
If you want to keep the ability to disable this feature at run-time for a short period of time just to be safe, I'm okay with that, as long as you commit to coming back and removing the env var guard after that -- let's say no longer than 1-2 releases. I don't want this cruft sitting in our code forever.
| @@ -80,10 +80,9 @@ | |||
|
|
|||
| namespace grpc_core { | |||
|
|
|||
| // TODO(donnadionne): Remove once RLS is no longer experimental | |||
There was a problem hiding this comment.
This TODO needs to stay, although you can change the assignee. We still want to get rid of this env var guard before too long.
There was a problem hiding this comment.
SG, I suspect this env var will be useful at least for upcoming weeks while we iron out possible RLS issues beyond the client.
Updated the comment to remove by 1.58
|
bazel c/c++ tool failure |
Integration tests are passing, so we should be ready to de-experimentalize. Related: internal bug b/265209578
copybara-service
bot
added
the
imported
Integration tests are passing, so we should be ready to de-experimentalize. Related: internal bug b/265209578
Integration tests are passing, so we should be ready to de-experimentalize. Related: internal bug b/265209578
Integration tests are passing, so we should be ready to de-experimentalize. Related: internal bug b/265209578
Integration tests are passing, so we should be ready to de-experimentalize.
Related: internal bug b/265209578