HParams: Update tb_http_client to support the hparams plugin backend take 2 #6340
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JamesHollyer
approved these changes
Apr 24, 2023
dna2github
pushed a commit
to dna2fork/tensorboard
that referenced
this pull request
May 1, 2023
…take 2 (tensorflow#6340) ## Motivation for features / changes As part of the effort to surface hparams data in the time series dashboard we need to start actually fetching it. The logic existed internally but for some reason was not previously available in OSS. I originally attempted this in tensorflow#6318 but due to incompatibilities with internal Colab had to revert it in tensorflow#6336. The issue was that Colab does not allow `POST` requests and our method of mapping POST requests to GET requests didn't meet the expectations of the hparams_plugin backend. I've improved the tb_http_client in tensorflow#6337 to now work with the hparams_plugin backend so this should now be fine ## Technical description of changes I mostly copied the internal code to the oss implementation and made a few small adjustments to imports. The biggest change is that I now utilize the `serializeUnder` parameter of our custom POST function to ensure the requests meet the expectations of the hparams backend ## Screenshots of UI changes ### enableHparamsInTimeSeries=false&tensorboardColab=false  ### enableHparamsInTimeSeries=true&tensorboardColab=false  ### enableHparamsInTimeSeries=false&tensorboardColab=true  ### enableHparamsInTimeSeries=true&tensorboardColab=true  ## Detailed steps to verify changes work correctly (as executed by you) I ensured all of the above states result in the runs table being displayed properly and that no errors are thrown by the hparams plugin backend
rileyajones
added a commit
that referenced
this pull request
May 9, 2023
## Motivation for features / changes The runs table currently contains the logic to filter runs by hparams, unfortunately, this logic is not shared with the rest of the dashboard and so filtering runs this way does not actually effect what is shown on the dashboard. ## Technical description of changes I moved out a lot of utility functions from the runs table container into common selectors. I then created three selectors 1) `getRenderableRuns` A private selector to help with the readability of `getFilteredRenderableRuns` Gets all runs associated with the provided experiment ids 2) `getFilteredRenderableRuns` Gets all runs associated with the provided experiment ids while accounting for filters. 3) `getFilteredRenderableRunsFromRoute` Retrieves the experiment ids from the route then gets the filtered runs associated with them NOTE: The utility functions are encapsulated in a utils object so that they can be spied on during testing See the PRs leading up to this #6340 #6360 #6361 #6323 #6324 ## Screenshots of UI changes (or N/A) N/A
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation for features / changes
As part of the effort to surface hparams data in the time series dashboard we need to start actually fetching it. The logic existed internally but for some reason was not previously available in OSS.
I originally attempted this in #6318 but due to incompatibilities with internal Colab had to revert it in #6336.
The issue was that Colab does not allow
POSTrequests and our method of mapping POST requests to GET requests didn't meet the expectations of the hparams_plugin backend.I've improved the tb_http_client in #6337 to now work with the hparams_plugin backend so this should now be fine
Technical description of changes
I mostly copied the internal code to the oss implementation and made a few small adjustments to imports.
The biggest change is that I now utilize the
serializeUnderparameter of our custom POST function to ensure the requests meet the expectations of the hparams backendScreenshots of UI changes
enableHparamsInTimeSeries=false&tensorboardColab=false
enableHparamsInTimeSeries=true&tensorboardColab=false
enableHparamsInTimeSeries=false&tensorboardColab=true
enableHparamsInTimeSeries=true&tensorboardColab=true
Detailed steps to verify changes work correctly (as executed by you)
I ensured all of the above states result in the runs table being displayed properly and that no errors are thrown by the hparams plugin backend