Renku users like using Renku to āhostā dashboards- they can build a dashboard in an interactive session, and then share that session or project link with a collaborator to easily share their work.
However, people expect āappsā on Renku to be ready on demand- they donāt want to wait for the session to launch.
In addition, one brand new piece of functionality weād like to offer is the ability to serve model endpoints with Renku āappsā. Currently, our URL stuff does not support that, and our concept of an interactive session does not support on-demand API requests (a session must already be running in order to respond to something).
And on the infrastructure side, if there are many people using an āappā, we donāt want to be running as many sessions as there are users running copies of the same app. Thatās an unnecessarily expensive use of resources. Instead, weād like to have a system that autoscales the app based on demand, including down to 0 when no one is using it.
6 weeks
This pitch proposes building a limited ābetaā apps feature, with a narrow scope (see Rabbit Holes) that we can test with users and get feedback on.
<aside> <img src="/icons/light-bulb_gray.svg" alt="/icons/light-bulb_gray.svg" width="40px" />
User Flow diagrams are here: ā£ (these diagrams cover both this pitch and Renku Jobs (UI) )
</aside>
https://www.figma.com/board/SqsBNlhGB0jSXPKUwy0SQd/Shaping-Boards?node-id=155-1218
First the user sets up a code repository with their app tool of choice and builds out their app.
To run the app in Renku, first the user creates a session launcher. When asked what kind of session launcher they want to create, they choose an App Launcher. From here, they can choose to create the environment for their app via either Create from Code or an External Environment. If they choose āCreate from Codeā, they select their code repository, and for a front end, they select a new option ācustom appā. In order to tell Renku how to run their app, either we here in the UI ask the user to enter the command to launch their app, or we instruct the user that their code repo must include a procfile that defines the launch command for the app.
The project now has an App Launcher. The App starts in inactive mode (terminology TBD!). The user can Activate the app. This makes the app available to be accessed, which opens the second half of the session box. Once the app is live, the user can Open the app. When the app is running, the user can get a share link, view logs, and shut down the app, so that no one can access the app and consume the appās resources.
<aside> <img src="/icons/stars_pink.svg" alt="/icons/stars_pink.svg" width="40px" />
Design Challenge: Unlike sessions, which are specific to a user (when I launch a session, only I have access to it), an app is either āonā or āoffā for everyone simultaneously. If one person turns the app on, it is accessible to everyone. If someone turns it off, it is no longer accessible to anyone. We should find some way of communicating this difference between Sessions and Apps in the design.
At a minimum, we need to remove the line of text at the top of the Sessions box (which should be renamed āLaunchersā) that talks about sessions being unique to you.
</aside>
An app can have the following statuses: