BYO software? #8
Replies: 1 comment
-
|
Is this software that runs inside the researcher's VM (or workspace- though IIRC we have very different definitions of what a workspace is), or software that requires additional infrastructure (e.g. shared web applications setup by an admin)? If it's the former then I think it should be up to the TRE administrators to determine what can be run, whether that's providing access to a mirror of curated packages, proxying approved external package repositories, providing an ingress workflow for software, or pre-installing a set of packages and denying everything else. I think it's in scope for K8TRE to provide the foundations for those though, e.g. a package mirror, or a repository proxy, which admins are free to use or not. If it's the latter then we're effectively talking about how arbitrary infrastructure interfaces with a K8TRE i.e. what are the interfaces or prerequisites, but the choice of what to run should be the admin's decision, not ours. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
A key design decision in the UCL ARC TRE is to allow researchers to ingress bring-your-own software and code.
Basis: research software manifests more both of heterogeneity and vulnerabilities than the software industry average, so effective central curation of packages is infeasible if the full gamut of research software is to be allowed. [a ref]
Design effect: the ARC TRE belabours project isolation (via network and VM isolation), to the extent that we are confident the risks are low even though the users even have root access on their project compute.
Will K8TRE be opinionated on this, or allow both BYO and curated software models for K8TRE-compliant TREs?
Beta Was this translation helpful? Give feedback.
All reactions