Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove jupyterhub-configurator in 1.0.0? #901

Closed
consideRatio opened this issue May 22, 2023 · 3 comments · Fixed by #912
Closed

Remove jupyterhub-configurator in 1.0.0? #901

consideRatio opened this issue May 22, 2023 · 3 comments · Fixed by #912

Comments

@consideRatio
Copy link
Member

consideRatio commented May 22, 2023

I'd like to propose we remove the opt-in setup of jupyterhub-configurator.

Overview

According to the docs, the configurator is disabled by default but is documented as something that can be experimetnally enabled.

If it is enabled, the Spawner get's an imported ConfiguratorSpawnerMixin that checks the relevant configuration just in time.

# Use the jupyterhub-configurator mixin only if configurator is enabled
# otherwise, any bugs in the configurator backend will stop new user spawns!
if cfg["services"]["configurator"]["enabled"]:
# Dynamically create the Spawner class using `type`(https://docs.python.org/3/library/functions.html?#type),
# based on whether or not it should inherit from ConfiguratorSpawnerMixin
UserCreatingSpawner = type(
"UserCreatingSpawner", (ConfiguratorSpawnerMixin, CustomSpawner), {}
)
else:
UserCreatingSpawner = type("UserCreatingSpawner", (CustomSpawner,), {})

What can be configured by the jupyterhub configurator is hardcoded in a tljh package bundled config file.

def set_configurator(config):
"""
Set the JupyterHub Configurator service
"""
HERE = os.path.abspath(os.path.dirname(__file__))
configurator_cmd = [
sys.executable,
"-m",
"jupyterhub_configurator.app",
f"--Configurator.config_file={HERE}/jupyterhub_configurator_config.py",
]
configurator_service = {
"name": "configurator",
"url": "http://127.0.0.1:10101",
"command": configurator_cmd,
}
return configurator_service
def update_services(c, config):
c.JupyterHub.services = []
if config["services"]["cull"]["enabled"]:
c.JupyterHub.services.append(set_cull_idle_service(config))
if config["services"]["configurator"]["enabled"]:
c.JupyterHub.services.append(set_configurator(config))

That declares that the default url can be configured:

c.Configurator.selected_fields = ["tljh.default_interface"]

Proposal motivations

  • We are heading for a 1.0.0 release and can do breaking changes as part of it
  • Enabling jh-configurator via tljh is hardcoded to only allow config of the default interface (default_url ?)
  • As a tljh jupyterhub admin one can use either the configurator to set default_url specifically, or use tljh-config or plain jupyterhub config .py files to do ~anything without the configurator. Should we really teach jh admins another way of doing things just to configure default-url in a simpler way?
  • jupyterhub-configurator is not versioned, so we reference fixed git hashes currently
  • tljh-config is already a shortcut to configure things by adding another configuration layer, adding another with the configurator can make it harder to understand how things work overall
@consideRatio
Copy link
Member Author

I think I've come to see providing the jupyterhub-configurator in TLJH to configure default url specifically, as done now, seems like commiting to constructing and maintaing a car, teaching users how to drive it, and then suggesting they can use it to drive a few meters they could have walked with ease.

With that analogy in mind, I suggest we don't try to help users drive it further and to a few new destinations, but instead help users be even more confident walkers able to get everywhere.

@yuvipanda @GeorgianaElena @manics what do you think about this? Okay to remove the configurator?

@manics
Copy link
Member

manics commented Jun 2, 2023

I've never used the configurator so I can't speak as to how useful it is.

Since the docs say

Because the configurator is under continue development and it might change over time, it is disabled by default in TLJH.

Removing it is fine if you think that's best.

@yuvipanda
Copy link
Collaborator

I would also like it to be removed, but for a different reason - I think my initial approach is a technological dead end. Architectural poor choices were made that came to light as we used it in production. See 2i2c-org/features#26 for more details.

I know that @GeorgianaElena spent a bunch of time integrating it into TLJH though, so would want to hear what she thinks too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants