re-configure envoy without restart?

[eitansuez]

Is your feature request related to a problem? Please describe.
no.

Describe the solution you'd like
when we run an envoy with func-e run -c <configfile>, if i later make a change to my config, the procedure is to ctrl+c the current envoy, and re-run the command. since envoy by default supports "hot reloading" of configuration, it would be cool if all one had to do was edit and save the config file for the changes to get picked up by func-e to push the updated config to envoy, without a restart.

Describe alternatives you've considered
ctrl+c and re-run the command.

Additional context
none

[codefromthecrypt]

hi there. I recall at some point we indirected the config file, but now we have tests that we don't mess with it. IOTW -c passes that arg directly to envoy and doesn't change the path to the config at all (it can even be in the current directory).

I also became confused as to what envoy actually supports vs what is done with scripts, and seem not alone envoyproxy/envoy#19515

It appears at first glance that it doesn't internally use inotify rather scripts to do that... That's an uneducated guess as I have no idea why you would need a script if it supported it internal. We probably need an envoy expert to answer that or docs to be clarified on the above envoy issue about if 'hot restart' support really means a python script. If that's all it means, then probably we could consider externalizing that here, but if internally it already does it and just no one knows how, maybe we can make an example instead

[dio]

Not sure if it is related, but we could possibly use dynamic configuration from filesystem: https://www.envoyproxy.io/docs/envoy/latest/start/quick-start/configuration-dynamic-filesystem, also see: https://www.tetrate.io/blog/envoy-101-file-based-dynamic-configurations/.

[eitansuez]

thank you for sharing your thoughts. this came up in a chat earlier today and it initially sounded very interesting and i wanted to make sure and capture it. i suppose the value of such a feature depends on the use case. if func-e is used in the context of experimenting with different configurations / learning, i'm starting to realize this "feature" is largely superfluous. in other contexts such as when envoy is an active participant in a larger system (i.e. a mesh) then leaning on its configuration api becomes important. and istio already does that.

[eitansuez]

thanks dio for the links.

[dio]

⚠️ This is a sketch ☢️

Please don't hate me because I do a silly thing like this 🙏🏽.

I'm starting to realize this "feature" is largely superfluous

@eitansuez So do you mean editing a "static"-config only scenario, is it the one we should have?

How about this: so when you have a valid config, for example from https://raw.githubusercontent.com/envoyproxy/envoy/main/configs/envoyproxy_io_proxy.yaml, you can do:

go run github.com/dio/pc@main func-e run -c ./envoyproxy_io_proxy.yaml

Then edit the YAML, Envoy will get a new config (see on the video I updated www.envoyproxy.io to www.google.com).

A complete command (download and run):

curl https://raw.githubusercontent.com/envoyproxy/envoy/main/configs/envoyproxy_io_proxy.yaml > config.yaml && \
go run github.com/dio/pc@main func-e run -c ./config.yaml

Screen.Recording.2022-02-04.at.18.05.27.mov

Also, the cmd+C sometimes doesn't cleanly stop envoy on macOS, haha. ps aux | grep func-e to help.

[eitansuez]

wow, that was easy!