-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[RFC] Extending the Tensorboard Notebook Display API #3752
Comments
Hi @jerrylian-db! Thanks for reaching out. A couple initial comments
With the understanding that this is just an example, in most cases we
I don’t understand from this example what the contract of the API is. If the idea is that this is a hard override that will affect all
Fair point. Related: User A points TensorBoard at a log directory to Let’s include the current user name/ID in the cache key to fix this.
It’s not quite that simple. Launching
To be clear, this is just the port-scanning logic. You can always pass |
Hey @wchargin. Thank you for your feedback! First, I apologize for the confusing example above. The way that we envision the API to work is for users to directly call the API on the from tensorboard import notebook
notebook.register_custom_display(custom_display) The example we first provided does the above whenever the
As you can see in https://github.com/tensorflow/tensorboard/pull/3770/files#diff-239d7f35cc0b4e0b6540bc796048880dR57, inside the In general, we hope to provide a general way of displaying Tensorboard in notebook environments that are not ipython-based. Creating this API creates a stable way of doing so. On process reuse, thanks for pointing out that it is the manager, not the binary that reuses Tensorboard processes. I’d also like to point out that in some multi tenant scenarios, users might share the same user id. I’m wondering if we can make the manager module look for an environment variable, perhaps called Thanks for the clarification on the port scanning logic. Yes, we would like to increase the scanning limit to 100. Basically, most users would just copy and paste examples from the web and expect those to work in multi-tenant environments. Requiring users to specify additional arguments adds friction. |
Increase the port scanning limit from 10 to 100 so that more users can start TensorBoard processes with default parameters in multi-tenant notebook environments. See #3752 for more context.
Another thought on process reuse. What are your thoughts on adding an argument to Tensorboard like |
My high-level concern is the following. The The approach proposed in the RFC and PR doesn’t seem quite there yet to
I recognize that these aren’t factual questions with clear correct
What do you think? |
(re: a new |
Three possible enhancements are proposed below to improve the Tensorboard experience on various notebooks environments. Please add your comments or concerns.
Custom Display API
A recent pull request made it possible for users to run Tensorboard in environments where the Jupyter host machine is not directly exposed to the notebook user. We are proposing to make the notebook display API more flexible.
The proposed enhancement is an API that lets users to directly set an inline display function that works in their environment, providing more flexibility for Tensorboard to be used on various notebook environments.
Here is an example use-case of this API.
Flag to prevent process reuse
Process reuse is a convenient feature when a single user runs Tensorboard on their personal machine. However, in multi-tenant environments where users share the same machine or container, reusing processes can lead to mutual interference. One possible scenario: user A starts a process on a log directory and user B starts tensorboard on the same directory, hence reusing user A's process. User B kills the Tensorboard process and user A's Tensorboard UI becomes stale (to user A’s surprise).
By adding a flag to Tensorboard that prevents process re-use, e.g.
--new_process
, users can set that flag by default to prevent interfering with each other on a multi-tenant environmentIncreasing the limit for the number of concurrent processes
Currently, there is a default and hard-coded limit of 10 concurrent Tensorboard processes in the port selection logic. For some environments, e.g. multi-tenant environments with powerful computing resources this is too restrictive. We propose increasing this default limit to 100.
The text was updated successfully, but these errors were encountered: