Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Change]: Questionnaire summary: Reproducible deployments #67

Closed
edwardchalstrey1 opened this issue May 18, 2023 · 2 comments
Closed

[Change]: Questionnaire summary: Reproducible deployments #67

edwardchalstrey1 opened this issue May 18, 2023 · 2 comments
Labels
proposed change A proposed change to the specification

Comments

@edwardchalstrey1
Copy link
Contributor

edwardchalstrey1 commented May 18, 2023

Summary

The percentage splits of responses to the SATRE survey question on the possibility of exactly reproducing a TRE with the same infrastructure.

Source

SATRE specification survey responses

Detail

Survey responses:

20.1.a. Reproducible TRE deployments (e.g. through infrastructure as code)

No opinion Not important Nice to have Important Essential
10.48% 0.00% 20.00% 33.33% 36.19%

Where

TRE required features

Proposal

Although essential was only just the most popular option, we should add reproducible deployments as a required feature. We probably don't need to be too prescriptive in saying that IaC is mandatory, just that some minimal level of reproducibility criteria is met e.g. documentation that people can follow.

Who can help

Anyone

Specification section

https://satre-specification.readthedocs.io/en/latest/pillars/computing_technology.html (see #110) Currently missing

@crickpetebarnsley
Copy link

I think we need to be a bit more specific on what is meant by reproducible. The TRE will be a key part of the FAIR delivery process for research projects. It needs to be specified to help as much as possible.

A TRE should be able to be built and set up to the same spec and with the same roles / users / parties etc. Either if rebuild is needed from an archive or due to platform failure.

A TRE should hold all ran code so that any operation on the data could be sequenced and reran (assuming the data is (made) available). This is can double up as a audit log for actions and allow query of queries to identify policy breaches and risks.

A TRE should hold logs of the versions of software and the library configs used for each stage of work in the research project - it will help the "lab notebook" part of record keeping. Having a standard set of things as a basic level for a TRE will allow a baseline level of research record logging.

@edwardchalstrey1
Copy link
Contributor Author

edwardchalstrey1 commented Jul 4, 2023

This is covered here: https://satre-specification.readthedocs.io/en/latest/pillars/computing_technology.html#deployment-management

Sone of your points @crickpetebarnsley are covered in that ^ and others in logging PR see - #132

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposed change A proposed change to the specification
Projects
None yet
Development

No branches or pull requests

2 participants