Envoy: Support .yaml.j2 and .json.j2 file suffixes for --config-path

Created on 23 Oct 2020  路  8Comments  路  Source: envoyproxy/envoy

Title: Support .yaml.j2 and .json.j2 file suffixes for --config-path

Description:
Envoy currently uses the file suffix to determine the file format being used, as described in the docs: https://www.envoyproxy.io/docs/envoy/latest/operations/cli#cmdoption-c

However, this is a bit inflexible. We call our config files envoy.yaml.j2, since they are Jinja templates that we deploy using Ansible. It makes sense to use the .yaml.j2 extension in this case, since it makes it more clear both to text editors and humans that this file supports Jinja template mechanisms.

However, this interacts poorly with Envoy:

$ envoy --mode validate --config-path overrides/foo/envoy/some_host_name/envoy.yaml.j2

[2020-10-23 10:55:07.743][4000][critical][main] [external/envoy/source/server/config_validation/server.cc:59] error initializing configuration 'overrides/foo/envoy/some_host_name/envoy.yaml.j2': Unable to parse JSON as proto (INVALID_ARGUMENT:Unexpected token.

If I rename the file to envoy.yaml, the validation succeeds without errors. As a workaround, I could add a symlink from envoy.yaml to envoy.yaml.j2 and make it "work" for now.

Suggestion

I think it would make some sense to add .yaml.j2 and .json.j2 as supported file extensions by Envoy. Of course, this does not mean that Envoy would magically understand Jinja syntax (this is completely out of scope for this issue), but it would make the process slightly smoother in cases where Jinja expressions are not being used (my use case currently).

I don't know if this is considered an edge case, but it's a bit annoying. If you agree that it would make sense to fix this, please point me to the appropriate part of the Envoy source and I'll happily submit a PR to support this. Thanks for a great project. :+1:

areconfiguration help wanted

All 8 comments

IMO a better way to handle this would be to allow a CLI flag to force a particular file format. I think this would avoid wackamole on file extensions?

Agreed on CLI flag for file format. We can still guess using extension as we do today but override with this flag.

Works for me, sounds good. :+1: Would you like me to give it a try?

Sure @perlun, I've assigned the issue to you.

Thanks @htuch. A pointer or two about where to start in this case wouldn't hurt. :smile: I haven't contributed any (code) changes to Envoy previously, but I'm probably able to figure the basics out if you point me in the right direction.

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

Sorry, I haven't gotten around to doing this. @mattklein123 - feel free to add the "help wanted" label and we might get someone to pick it up.

Was this page helpful?
0 / 5 - 0 ratings