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

Added support for named-servers #78

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

scj643
Copy link

@scj643 scj643 commented Feb 11, 2021

Append the server name to the unit to allow named servers. This closes #73

This could use a better way of handling templating.

@welcome
Copy link

welcome bot commented Feb 11, 2021

Thanks for submitting your first pull request! You are awesome! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please make sure you followed the pull request template, as this will help us review your contribution more quickly.
welcome
You can meet the other Jovyans by joining our Discourse forum. There is also a intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

@yuvipanda
Copy link
Collaborator

Hello! Thank you for opening this :) I think expanding {servername} is probably the way to go. Maybe steal this code from kubespawner? Not sure if we need the legacy support. We can then set the default template.

@scj643
Copy link
Author

scj643 commented Feb 11, 2021

I changed it to use _expand_user_vars and to rstrip any trailing -s

Copy link
Member

@GeorgianaElena GeorgianaElena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work @scj643, thank you! 🎉 It would be great if you could also update the README, so that folks know about the named servers support? (maybe here).

@yuvipanda, the readme says that unit_name_template should contain only [a-zA-Z0-9_-]. What happens if it doesn't (let's say because of servername)? Should we ensure this restriction by using something like escapism, similar with what kubespawner does here?

@yuvipanda
Copy link
Collaborator

That's actually a good catch, @GeorgianaElena! Using escapism seems the right way to do it.

Copy link
Member

@GeorgianaElena GeorgianaElena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @yuvipanda :)

@scj643, do you want to make sure we're having a unit name that respects the restriction in the readme by using escapism? ❤️

It should be fairly similar with what happens in kubespawner, with the difference that an _ is a safe character for the systemd unit name:

systemdspawner/systemdspawner.py Outdated Show resolved Hide resolved
systemdspawner/systemdspawner.py Outdated Show resolved Hide resolved
Added checking for string length when escaping.
Added option for striping trailing character for _expand_user_vars.
Made escape_char configurable.
Comment on lines +152 to +164
unit_trailing_character = Unicode(
'-',
help="""
When using a unit that ends in a SERVERNAME strip this character from the end of the parsed string.
"""
).tag(config=True)

escape_char = Unicode(
':',
help="""
The character to change invalid safe characters to.
"""
).tag(config=True)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making these configurable might open up the room for possible miss configurations. Let's just add this info in the help description of unit_name_template.

help="""
Template to use to make the systemd service names.

{USERNAME} and {USERID} are expanded}
{USERNAME}, {SERVERNAME}, and {USERID} are expanded}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{USERID} has been replaced by {USERNAME} for the unit name, so it can be removed as it's not longer used.

Comment on lines +181 to +184
if len(in_string) > self.max_unit_length:
self.log.warning(f'String is longer than {self.max_unit_length}')
# Slice the string to the max unit length
return escapism.escape(in_string[:self.max_unit_length], safe=self.safe_chars, escape_char=self.escape_char)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that rather than slice the unit name ourselves if it exceeds max length, we should instead throw an error if this happens.

The reason why I think this would be better is because if we slice it, the unit name will not respect the template anymore, and one might end up with duplicates.

USERNAME=self.user.name,
USERID=self.user.id
)
USERID=self.user.id,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

USERID can be removed from here also, as it's not used anymore for the unit name.

).tag(config=True)

# Characters that are safe for systemd units.
safe_chars = set(string.ascii_lowercase + string.digits + string.ascii_uppercase + ':-_.\\')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The escape character cannot be in the list of safe chars. Not sure if this causes an error or a warning, but it's best to remove it.

@littleyoda
Copy link

Is there any chance that someone will take on this PR again?

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

Successfully merging this pull request may close these issues.

Support use of JupyterHub.allow_named_servers
5 participants