Specify models on a per-environment basis

[steven-cd]

The selection of models that is executed is currently determined by the contents of models.yml in the web-ui repo. This means that the set of models is always the same for each deployment. It's looking like we might want to have multiple deployments that have different sets of models (or different versions) on each.

I can think of a number of solutions:

• Keep the existing models.yml, and add some environment variable that is used to filter the list by model slug.
  • This can then be set in the infrastructure definition of the container.
  • The downside to this is that it means that models can only be on or off - if a new version of a model had different information (e.g. supportedParameters) we wouldn't be able to support that
• Volume-mount a models.yml file into the container.
  • We could keep the existing one in the web-ui to be the default set for local development.
  • That would let us vary everything, but has the downside that it would need us to replicate the information in a bunch of places, which will be awkward if we need to change a description etc.
• Dynamically pull the information from somewhere
  • In model-connector-template, we've suggested that modellers write a meta.yml that contains the metadata, but the file isn't actually directly used, it's just a template for later copying into models.yml. There might be some way to make this information available (through a Docker LABEL?), that we could then pull automatically either at run-time, or in infrastructure with a volume-mount as above
  • You'd still need some configuration to be done through variables, but it would just be the imageURL, not everything else
  • This has the advantage of not replicating information, and also of making the workflow for modellers to submit their model a bit easier
  • Downside to this is that it's a lot more complicated to do

Note that there is an isProductionReady flag in models.yml which can be used to hide some models, but it's not really sufficient for these needs (and should probably be removed)

[kavousan]

Without Manchester involvement no concrete use case.

[steven-cd]

I realised that one other possible solution to this would be to store the information in the database. This has the advantage of putting it with other information that we might want to vary per-environment (the nations/regions in the dropdown). The downside is that that data is currently managed through migrations, and the migrations themselves are essentially part of the codebase. We'd have to address that somehow, either by keeping the related migrations in the codebase but segregating them by environment somehow (scoping?), or possibly by moving them into the infrastructure repo

[steven-cd]

This is now partially supported by the use of an .override/models.yml file in the web-ui, but because that file is read at build-time (unless someone with more webpack knowledge than me can unpick that), it means building a separate Docker image for each deployment (e.g. .github/workflows/ci-staging in web-ui), so it's still far from an ideal solution. All the above suggestions are still better solutions.