Over the last weeks I have been having discussions with the discovery team and the service ops team about the future deployment of some static sites around the wikidata query service world.
Sites of interest:
- **Wikidata query service UI** (currently deployed on wdqsxxxx hosts)
- **Wikidata query service query builder** (currently under development)
Status Quo:
- The fact that the query service UI is deployed on wdqsxxxx hosts makes it harder than it could be to perform deployments. The deployment process is primarily controlled by the discovery team.
- The new query builder needs somewhere to be deployed
- The discovery team would rather not deploy more things to the wdqsxxxx hosts
- Many previous discussions around blubberizing the wdqs ui have said at times that k8s for static sites (if done separately) could be a waste of resources.
- Serviceops however said that it could still be okay? (TBA comment reference)
###Requirements
* Teams that manage / own the sites should be able to update the content of the site
* The hosting location can be pointed to from sub paths of query.wikidata.org (and similar flexible locations). For WDQS this could be done in the WDQS nginx server config
>>! In T264710#6532140, @akosiaris wrote:
> * **Support for structured logging to stdout** to allow debugging issues via our ELK stack should be a requirement.
> * **Support for exporting metrics via prometheus or statsd should be a requirement**. This should allow debugging issues, establishing SLIs and SLOs and allowing to come up with a level of support and ownership of powered services. Failing that, it will be impossible to come up with a level of support and will make those static sites a best effort.
###Ideas
####A) Service per site
Each static site would be deployed as it's own service. (Possibly using a very templated base image)
| Pros | Cons |
|------------------------|----------------|
| Simple Services | More hardware resources |
| | More wiring overhead |
####B) One service to rule them all
Discussed in serviceops IRC channel in September / October 2020
A single image and service would be developed to host "all" static sites
**Content of sites within a single image**
| Pros | Cons |
|------------------------|----------------|
| Runtime resource minimization | Single point of failure for all static sites |
| Self contained service | Complex image to be created, managed and maintained |
**Content on swift or some other shared storage**
| Pros | Cons |
|------------------------|----------------|
| Runtime resource minimization | Single point of failure for all static sites |
| | Interaction with another service (swift?) |