adding launch parameter to allow remote access to containerized OWL

[didier-durand]

Hi,

In multiple use cases, when running on the cloud, OWL needs to allow remote access to Gradio UI. The server_name parameter of app launch() defines which ip adresses have access to the OWL ui.

default value 127.0.0.1 (aka localhost) which is default doesn't allow for remote access (local host is not routable). So, we define a new ENV var OWL_SERVER_NAME (easy to define at container start) that allows to replace the default by new one.

In our use case, we use "0.0.0.0" (all ip adresses) as value for ip addresses when starting our OWL container. It works just fine.

[Wendong-Fan]

thanks @didier-durand , from gradio's documentation https://www.gradio.app/guides/environment-variables the port and server could be set by setting the environment variables, I think it's better for us follow gradio's native setting, WDYT?

[didier-durand]

Hi,

I see a few reasons why introducing OWL_SERVER_NAME is better than relying on GRADIO_SERVER_NAME documented at https://www.gradio.app/guides/environment-variables:

1. The list of Gradio env variables is incomplete: for example, no way to give the path to SSL certificate via env var while it is present in app.launch (param ssl_key_file). Same thing for params authand auth_message`. For secure productive deployments those parameters will be required. So, when containerized, Owl will require a mechanism though env vars for those params like the one proposed here with OWL_SERVER_NAME
2. When using GRADIO_SERVER_NAME to pass the name, we cannot be sure when Gradio uses this variable to set the server name as app.launch() is NOT the first call to Gradio in the current webapp.py script. So, in the future if based on some other parameters and variables, Owl needs to change server_name calling app.launch(), GRADIO_SERVER_NAME may already have been set via the reading of this variable and it will be too late. So, Owl loses some control by using GRADIO_SERVER_NAME.

So, for 1/ sake of homogeneity in (upcoming) Owl launch parameters when containerized and 2/ fine-grained control of launch mechanism, I think that creation of OWL_SERVER_NAME makes sense.

[didier-durand]

@Wendong-Fan
Hi, can you please decide if this PR is accepted (and merged) or closed? (any choice is fine for me)
I have others to submit that will depend on the way forward that you choose.
Thanks