BinderHub is slowly gaining the ability to move beyond running on Kubernetes with Docker.
This is the first step to make it possible to configure parameters specific to the underlying infrastructure (Kubernetes, Docker, Podman, Local, etc). I've tried to minimise the changes.
The build.py changes look very large, but it's mostly rearranging the existing code:
Common parameters and methods are moved out of Build and into the Traitlets based BuildExecutor base class (suggestions for alternative names welcome- if we want backwards compatibility we have to keep the generically named Build class as the Kubernetes builder)
K8S specific methods are moved from Build to the Traitlets based KubernetesBuildExecutor
The original Build class is now just a wrapper class around KubernetesBuildExecutor. The Build.__init__ function signature is unchanged, so hopefully if someone's subclassed it their class should still work with binderHub.
builder.py now checks whether the BuildClass is the old existing Build or the newer BuildExecutor based classes. If it's the former the behaviour is unchanged. If it's the latter then parameters should be set using Traitlets in a config file or similar, the current BinderHub command-line args will be ignored.
For some reason switching to Traitlets surfaced a unset IOLoop.current(), so I've switched to avoiding tornado.ioloop.IOLoop.current()other than in the BinderHub initialization code. Instead the loop is passed as a parameter to theBuild*` classes. I can try and split it into a separate PR if you prefer but it'll end up conflicting here due to the refactoring.
BinderHub is slowly gaining the ability to move beyond running on Kubernetes with Docker.
This is the first step to make it possible to configure parameters specific to the underlying infrastructure (Kubernetes, Docker, Podman, Local, etc). I've tried to minimise the changes.
See:
The
build.py
changes look very large, but it's mostly rearranging the existing code:Build
and into the Traitlets basedBuildExecutor
base class (suggestions for alternative names welcome- if we want backwards compatibility we have to keep the generically namedBuild
class as the Kubernetes builder)Build
to the Traitlets basedKubernetesBuildExecutor
Build
class is now just a wrapper class aroundKubernetesBuildExecutor
. TheBuild.__init__
function signature is unchanged, so hopefully if someone's subclassed it their class should still work with binderHub.builder.py
now checks whether the BuildClass is the old existingBuild
or the newerBuildExecutor
based classes. If it's the former the behaviour is unchanged. If it's the latter then parameters should be set using Traitlets in a config file or similar, the current BinderHub command-line args will be ignored.For some reason switching to Traitlets surfaced a unset
IOLoop.current()
, so I've switched to avoiding tornado.ioloop.IOLoop.current()other than in the BinderHub initialization code. Instead the loop is passed as a parameter to the
Build*` classes. I can try and split it into a separate PR if you prefer but it'll end up conflicting here due to the refactoring.This PR currently includes unmerged PR: