Expose kernel_info_timeout configuration

[lresende]

No description provided.

[lresende]

@kevin-bates could you take a look and see if I forget any places related to exposing this new property

[kevin-bates]

Hi @lresende. Aside from the comments posted here, I have some other comments/questions:

1. Could you please update the PR's description with what this is, and why it is necessary? I'm assuming its something about the time to receive the kernel_info_reply and is why its default spans that of KERNEL_LAUNCH_TIMEOUT.
2. What enforces the info timeout? In process proxy we enforce the launch timeout if we have not received the connection info after that period of time. I don't see similar for kernel-info.

Since the kernel-info response is really handled via the websocket negotiation logic - which EG doesn't provide code for, it seems like this really needs to be part in JupyterServer rather than EG since there's no place for the enforcement. Hmm, and checking JupyterServer, I see kernel_info_timeout is defined there already so I guess I'm confused.

Why does EG need to be concerned about this at all? Seems like this is fully configurable (and usable) from the client entirely.

[kevin-bates]

Perhaps use the same text as the EG_ variable (once clarified by previous comment), but also please add how this is different (e.g., this only applies to the single kernel launch because its conveyed from the client or something).

[lresende]

2. What enforces the info timeout? In process proxy we enforce the launch timeout if we have not received the connection info after that period of time. I don't see similar for kernel-info.

By exposing the property here and passing it to kernel manager, won't it be managed/enforced on the parent class? or are you saying I need to add additional support for enforcing on our side? this seemed to have worked on tests...

--RemoteMappingKernelManager.kernel_info_timeout=${EG_KERNEL_INFO_TIMEOUT}

[lresende]

1. Could you please update the PR's description with what this is, and why it is necessary? I'm assuming its something about the time to receive the kernel_info_reply and is why its default spans that of KERNEL_LAUNCH_TIMEOUT.

Yes

[kevin-bates]

By exposing the property here and passing it to kernel manager, won't it be managed/enforced on the parent class? or are you saying I need to add additional support for enforcing on our side? this seemed to have worked on tests...

--RemoteMappingKernelManager.kernel_info_timeout=${EG_KERNEL_INFO_TIMEOUT}

Ah, sorry, you're right, EG does inherit most all of the plumbing for starting the kernel (not close enough to this anymore). So you shouldn't need any of the changes in the RemoteKernelManager since kernel_info_timeout pertains only to the MappingKernelManager (and its subclasses). As a result, from an EG config perspective, I think all that you need is EG_KERNEL_INFO_TIMEOUT. Calling the command line with --RemoteMappingKernelManager.kernel_info_timeout=${EG_KERNEL_INFO_TIMEOUT} should just work (since RMKM is subclass or MappingKernelManager), no need for any of the changes in remotemanager.py or processproxy.py or need to document KERNEL_INFO_TIMEOUT. You do need the shell and yaml changes, provided you want your value set from the env or command line.

((Of course, I probably something wrong here, but if my memory serves me correctly (fat chance) I believe this can be trimmed down to essentially documenting the EG variable and CLI.))

[lresende]

@kevin-bates sorry it took a little while to get back to this, but I believe I did the cleanups necessary, let me know what else needs to be done here...

[kevin-bates]

Just one doc cleanup then we're good.

[lresende]

Just one doc cleanup then we're good.

@kevin-bates done, also rebased so the doc builds should be passing now

[kevin-bates]

Thank you!