Use CLI flags for configuration instead of environment variables

[sisp]

Expected Behaviour

of-watchdog should be configurable using CLI flags instead of environment variables.

Current Behaviour

of-watchdog is only configurable using environment variables.

Possible Solution

Add CLI flags for configuration. To retain backward compatibility, environment variables can be used when no CLI flags are provided. If at least one CLI flag is provided, environment variables should be ignored and the default value of any unprovided CLI flag should be used instead.

Context

of-watchdog starts a webserver in a child process, i.e. of-watchdog and the actual webserver run in the same environment (typically a Docker container). It is possible (and likely) that the webserver is also configured using environment variables, and there is a chance that some environment variables are the same for of-watchdog and the webserver. This can lead to a bad configuration, e.g. if the webserver uses the environment variable port (which is used by of-watchdog, too), of-watchdog is configured to listen on the same port as the webserver which (a) is unexpected and (b) leads to a port collision.

[alexellis]

Hi @sisp environment variables are used to configure 12-factor apps rather than flags.

I would consider the variables used in the watchdog as reserved.

Unless you have a concrete problem, where this is clashing for you and causing an issue, I'd suggest we leave things as they are and close this issue.

Thank you for your concern.

Alex

[sisp]

Hi @alexellis, I automatically extend user-provided Docker images with of-watchdog, so they can be deployed to OpenFaaS without additional effort for the user. I could declare the of-watchdog variables as reserved, but I don't think this is a clean solution because from a user's perspective of-watchdog doesn't exist and I'd like it to be only an implementation detail of my "platform".

If you have a strong opinion about using environment variables, how about prefixing the of-watchdog variables, e.g. of_watchdog_*, to reduce the chances of name collisions? This would be a breaking change to be effective, though.

[alexellis]

I'm unaware of your usage of OpenFaaS and this is the first time we've heard from you. It may make your case stronger, if you're seen to participate in the community and build some goodwill and relationship with the community.

For your reference, here are a list of environment variables in use.

https://github.com/openfaas/of-watchdog#configuration

If you can show this to be a genuine problem rather than a hypothesis, we would give it some more thought. So far this hasn't been any issue that we've been aware of by any of our users.

Alex

[sisp]

I'm unaware of your usage of OpenFaaS and this is the first time we've heard from you. It may make your case stronger, if you're seen to participate in the community and build some goodwill and relationship with the community.

That's true, I've been using OpenFaaS for about a year and it has worked great so far, so there was no need to engage on GitHub. But I'm happy to discuss with the larger community about my case.

For your reference, here are a list of environment variables in use.

https://github.com/openfaas/of-watchdog#configuration

Thanks for referencing the configuration list. I'm aware of it and understand how of-watchdogworks.

If you can show this to be a genuine problem rather than a hypothesis, we would give it some more thought. So far this hasn't been any issue that we've been aware of by any of our users.

I'm building a small wrapper CLI around faas-cli deploy to allow users to deploy their already dockerized web services to OpenFaaS without the need to explicitly add of-watchdog. In fact, they shouldn't even know what of-watchdog is, how it works, and that it is needed. To them, my CLI is just a CLI to deploy a Docker image to a platform. Therefore, I'd like to avoid unexpected side effects due to environment variables needed to configure of-watchdog that could collide with environment variables of the users' Docker images.

Does this make my case a bit clearer? 🙂