Use Case: Renku for sharing analysis results
Some people (such as ‣, one of the groups that came to us through the 2024 SDSC Call) use Renku to share analysis results with their customers. They have a standard code libraries and visualization dashboards that they use for each engagement. They find it cumbersome that for each Renku project they have to re-configure up the same environments for their visualization dashboards each time. And, if they make a change to the environment, the changes don’t propagate in any way, so they have to go through and change the configurations in each of the projects manually.
Use Case: Propagating changes in (copied) teaching environments
Similarly, in teaching (‣) instructors sometimes need to make a change to the session environment in the middle of the course. In cases where students make a copy of the instructor’s project, this change in the parent project does not propagate to the copied projects.
Use Case: Enabling environment curation and reuse
Some people would like to use Renku to accomplish a specific data task (examples: curate a dataset for publication, make a prediction using a specific software suite). Technical specialists on their team have created the environment necessary to accomplish this task. The analyst wants to spin up this environment, attach the data they need, and complete the task at hand, without having to worry about creating or configuring the environment to run on Renku. They want to reuse that environment as-is; I don’t need to modify it (and do I have the skills or interest to do so!)
Now that we have jobs and apps, a user may start with a session, create an environment there, and then create a job launcher to run a specific task. They probably want the job to use the same environment that the session uses, but right now in Renku you have to create a whole new environment for each launcher. This means that if you make a change to the session environment (add a dependency), you might forget to make the same change to the job launcher environment (forget to rebuild it). Or, if you swap out an external image in one, you have to remember to do the same (including re-entering the configuration) for the other launcher.
6 weeks
We want to make environments shareable and linkable between projects, just like data connectors (’DCs’). Just like DCs, environments can be owned by a project, group, or user, and can be public or private.
This new functionality represents quite a change to Renku! For that reason, for this cycle we want to do design exploration and user research before starting with implementation.
In addition, while we’re considering substantial changes to the project page, we’d like to take the opportunity to revisit the project page as a whole.