new sessions/amalthea cleanup

[Panaetius]

There's several smaller issues with the new amalthea and sessions in data services code. This issue serves as a tracking issue for them.

• ImagePullPolicy is set to IfNotPresent for custom images, so something like :latest won't update
• Editing some settings on the environment doesn't propagate when unhibernating sessions and there's no warning that a full restart is needed to apply the changes. E.g. users id, entrypoint, image tag.
• All the k8s environment variables are available in sessions, we should probably limit that to only necessary ones:
• On session start there's sometimes a warning about the gateway being misconfigured. after refreshing, the session works.
  

[leafty]

Editing some settings on the environment doesn't propagate when unhibernating sessions and there's no warning that a full restart is needed to apply the changes. E.g. users id, entrypoint, image tag.

This is most likely good by design. Any of these changes could render the session un-resumable, so it is best to freeze the launch settings.

ImagePullPolicy is set to IfNotPresent for custom images, so something like :latest won't update

We should probably open a full issue to implement image de-referencing at session launch.

[Panaetius]

This is most likely good by design. Any of these changes could render the session un-resumable, so it is best to freeze the launch settings.

yes but as mentioned, we should inform users of this. And it's no just when unhibernating, also if the session failed to launch and is backoff restarting. How this will manifest for users when trying to create a custom image session is that they will set up the session and type e.g. a wrong entrypoint, they will edit the session to fix it, click launch again, and it will still fail because it's still using the old settings. So really there's two things, one is not informing users that the session needs to be fully stopped for changes to apply (or make it a conscious choice with a button that allows force-applying it?), and two that when session start failed, no shapshot should be created and changes should be applied immediately (or a failed session should be stopped completely? only if there were no previous successful launches?).

To give an more tricky example, I'm playing with buildpack images right now and those run as user 1002, but we default to user 1000. The session will actually start and run for a second, and then fail due to a permission error, which I see in the logs. So I change UID to 1002 and click launch again, and it'll still fail because it's still UID 1000.

[leafty]

To give an more tricky example, I'm playing with buildpack images right now and those run as user 1002, but we default to user 1000. The session will actually start and run for a second, and then fail due to a permission error, which I see in the logs. So I change UID to 1002 and click launch again, and it'll still fail because it's still UID 1000.

Wait, why does this happen? The launch process should use the current settings from postgres.

[leafty]

one is not informing users that the session needs to be fully stopped for changes to apply (or make it a conscious choice with a button that allows force-applying it?)

This is a UI issue and needs to be tracked there.