Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix command line arguments for worker getting overridden #1547

Closed
kshyju opened this issue May 18, 2023 · 1 comment · Fixed by #1897
Closed

Fix command line arguments for worker getting overridden #1547

kshyju opened this issue May 18, 2023 · 1 comment · Fixed by #1897
Assignees
Labels
enhancement New feature or request

Comments

@kshyju
Copy link
Member

kshyju commented May 18, 2023

PR #583 changed the order or registering configuration sources so that environment variables will be registered before command line arguments. This change fixed issues where the environment variables were overriding the command line argument values (ex: port number for GRPC communication) and that causes worker failing to start.

Looks like this issue was impacting our Linux use cases.

Azure/azure-functions-host#7555
#524

The fix was made to the worker code. But this does not prevent the issue completely because customer can add environment variables as a configuration source after the "ConfigureFunctionsWorkerDefaults" method call in the worker main code.

var host = new HostBuilder()
.ConfigureFunctionsWorkerDefaults()
.ConfigureAppConfiguration(builder => builder.AddEnvironmentVariables())
.Build();

This code causes worker to fail when trying to GRPC handshake. (in Linux + VNet use case)

The workaround is to swap the order as below

var host = new HostBuilder()
.ConfigureAppConfiguration(builder => builder.AddEnvironmentVariables())
.ConfigureFunctionsWorkerDefaults()
.Build();

#1500 is an issue where customers ran into this situation.

There were few ideas discussed in the hallway conversations, updating the worker code to check for command line arguments with FUNC prefix (Ex: FUNCTIONS_GRPC_PORT) and use that value if present, else fallback to existing implementation (using PORT argument). Another approach is to pass this information worker needs via environment arguments.

@jviau
Copy link
Contributor

jviau commented May 22, 2023

With proper IConfiguration and IOptions usage, we can make the cmd line or environment variable approaches both work and be completely interchangeable. Infact, the root cause is less what mechanism we use to get the values into functions, and more that we used very generic values. If we switch to FUNCTIONS__HOST__URI or FUNCTIONS__GRPC__URI, then these automatically map into IConfiguration as "functions:host:uri" and "functions:grpc:uri". We then have enough insolation on those variables to avoid collisions - which is what was happening. As "HOST" and "PORT" are very generic env vars that are much more likely to already be set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants