You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Envoy reads all runtime config info from the filesystem. Changes to runtime need to be done on a separate copy of the filesystem tree, followed by a symlink swap.
For certain deployment scenarios, it might be easier and flexible to pull runtime info from a REST/gRPC backend similar to the SDS API.
If one were to add a network backend to the runtime, in addition to a file system backend, how should the APIs look like?
The text was updated successfully, but these errors were encountered:
This relates to #298 . Lots of runtime configuration are provided as part of RDS api. Granted that there are also a lot of other runtime settings that are not in RDS. But I just wanted to bring up the RDS overlap.
Closing for now. With RDS, CDS, and SDS, adding another network work backend for runtime seems to overcomplicate the system. Its far easier to live with a file-system based backend, as it makes it easier to reason about the state of the Envoy process.
Currently Envoy reads all runtime config info from the filesystem. Changes to runtime need to be done on a separate copy of the filesystem tree, followed by a symlink swap.
For certain deployment scenarios, it might be easier and flexible to pull runtime info from a REST/gRPC backend similar to the SDS API.
If one were to add a network backend to the runtime, in addition to a file system backend, how should the APIs look like?
The text was updated successfully, but these errors were encountered: