Containerized Client #217
Containerized Client #217
Conversation
| @@ -8,6 +8,10 @@ webapp_ctx: =c= Tomcat webapp context name, e.g. toxo.qa | |||
| _webapp_ctx: '{{ webapp_ctx|prod_prom_ctx(hostname) }}' | |||
| product: '{{ project }}' # product: ClinEpiDB vs. project/model: ClinEpiDB or Gates | |||
|
|
|||
| # Client Container Config | |||
| webapp_host_uri: =c= URI (URL or path) under which the client code container is exposed (if it is a path, it MUST begin with /) TODO SET ME HERE WHEN THE CONTAINER IS DEPLOYED!!!! | |||
There was a problem hiding this comment.
I feel like this is always "https://{{hostname}}/client-bundle-service", no? Or did we decide to appoint a URL e.g. veupathdb.org and then deal with the CORS issues? (with "client-bundle-service" being a stub name TBD later). You do need to put that extra string in somewhere (i.e. the apache mapping name, like "eda" or "site-search"). Should decide what it will be for the client code service.
There was a problem hiding this comment.
Right now it is this way so that it can be configured to be either a relative path:
webapp_host_uri: /client-bundle-serviceor a remote URL for testing with locally hosted client code:
webapp_host_uri: https://f84e-2600-4040-70fa-ee00-9cb2-1473-b230-a66f.ngrok-free.appIf this is undesirable it can be changed when we get the thing deployed, but we will be cutting off our ability to localhost client code to run on a dev server.
There was a problem hiding this comment.
I'd prefer to keep this in place.
Also, it might be nice to use a single host for all sites, since users will reap the benefits of caching once across all sites. However, I'm not sure if CORS will become an issue (I think not, but would have to look more closely). We can play with that once the thing is deployed.
Changes necessary to support a containerized client host.
WARNING This cannot be merged until:
defaults.yml