We want the transition from 1.0 to 2.0 to feel polished. Currently, a user can manually set up a 2.0 project with their 1.0 project repo and docker image. But this is a cumbersome process. It shouldnât be too had to automate the majority of cases, and that would give a much nicer user experience.
In addition, weâd like as many as possible users and projects transition to 2.0, and this is more likely if we make that process easier.
6 weeks
We add a banner to 1.0 projects saying that âthis version of Renku is deprecated. Please migrate your project to Renku 2.0â.
This banner includes a button to migrate the project into a 2.0 project.
This banner also includes a link to get help, which opens an email to us.
[Maybe, if it fits] this banner also includes a learn more link to a blog post describing what 2.0 is all about, and differences between 1.0 and 2.0.
Hereâs what this migrate button does (and doesnât do):
| Project component | How itâs transitioned to 2.0 |
|---|---|
| Namespace (owner) | User is prompted to select a 2.0 namespace (defaults to their own) |
| [nice to have] option to create a new group, so the user doesnât have to flip back and forth between 1.0 and 2.0 to create the group and come back. | |
| Project members | GitLab repository members and GitLab groups are NOT MIGRATED. Warn the user that they need to add project members and create these groups in 2.0. (Also, Advertise that this is a new feature that is now much easier to do in 2.0!) |
| Project visibility | Prompted? Default to same? (internal â private? [internal doesnât exist in 2.0]) |
| Project name, description, keywords | copy to the new project |
| Project avatar | Not copied into the new project |
| Code repo | The GitLab repo is attached to the new project automatically |
| Session Launcher + Env | A new session launcher is created automatically: |
| ⢠session launcher name: use template name or name of the base image (âplus the date, to denote that it wonât update?!) | |
| ⢠environment: set as the last created docker image. | |
| [nice to have] Support migrating the pinned image as the launcher env if it exists, rather than the latest docker image. | |
| (Maybe create this as an additional launcher, with ââŚpinnedâ in the title to distinguish it from the other one?) | |
| Data connectors | Link/Copy cloud storage from the 1.0 project into the 2.0 project |
| (Renku 1.0 datasets) | Warn user that this mode of data is no longer recommended. They can continue to use LFS data in their session (itâs in the code repo), but they are recommended to switch to using 2.0 data connectors for a better experience and easier sharing. Link to blog post describing the difference. |
| Only show this warning message if the user has a renku dataset in the project. | |
| [nice to have] Pre-populate the project documentation with info about the dataset(s) in git LFS | |
| (Renku workflows) | Warn user that Renku no longer maintains a custom workflow tool. They are welcome to continue to use the renku CLI in 2.0 (itâs in the current base images). |
| Only show this warning message if the user has a renku workflow in the project. |
Once the project has been migrated:
The 1.0 page shows a deprecation banner that says this âproject has been migrated to a newer version of Renkuâ, with button to go to the 2.0 version of the project.