A minimalistic proposal to replicate some of the workflows coming from the pBHub experience.

[damianavila]

Context

In a recent conversation with @consideRatio, he outlined what he thinks (and I agree with) would be a minimalistic implementation proposal to "basically" replicate some of the workflows in the pHub experience.

This would be based on (or part of) the basic building block he is working on at https://github.com/consideRatio/repo2docker-service.

The idea of this issue is further specifying this proposal so we have a clear picture of the additional piece we would be to implement.

Proposal

Minimalistic proposal:

This would be in the scope of the minimalistic solution:

1. /services/repo2docker allows users to build images
2. Glue in jupyterhub configuration makes /hub/spawn presents options on how to spawn a server based on pre-build images via repo2docker-service
3. Glue in jupyterhub configuration makes it possible to launch a server based on a link
4. Documentation or a webpage, maybe even /hub/spawn is provided to construct a link to launch a specific pre-build image

This might be out of scope (because brings additional complexity):

• To have users press a link that triggers a build followed by a launch, without having an image pre-built.

Updates and actions

Some updates trying to explain a little bit more about the goal/story behind this issue:

1. There is currently a base building block being developed in https://github.com/consideRatio/repo2docker-service.
2. That building block is bringing image-building capabilities as a new JupyterHub service.
3. That building block does NOT replicate the workflows already present in the pBHub because it is designed to be a building/basic/underlying block.
4. The "minimalistic prototype" represents the first iteration of a model that could potentially capture some of the workflows already present in the pBHub experience although re-interpreted from the JHub "optics".
5. The "minimalistic prototype" needs further specification and clarification and it is just an opinionated minimal POC of what that service may look like in the future. That prototype should be informed and fed with input coming from UI/UX research, where the launch links discussion in Launch Link specification discussion #1931 is one of the most important points to address.
6. This issue is the place to discuss those specifics that need to be further elaborated, prototyped, and eventually agreed upon/confirmed. In my mind, the end and final result of this issue should be a solid prototype that fulfills several of the requirements/deliverables agreed in the agreement and, eventually, evolve (given the experience we collect along the way) into a final product.

[damianavila]

Superseded by #2120 and 2i2c-org/binderhub-service#27