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
Scottx611x/provide vis tools with url to their input data #2677
Scottx611x/provide vis tools with url to their input data #2677
Conversation
…_vis_tools_with_url_to_their_input_data
…rovides a nice "Please Wait" page, so this seems like a natural move
…e removed on django_docker_engine side
Codecov Report
@@ Coverage Diff @@
## develop #2677 +/- ##
===========================================
- Coverage 57.84% 55.47% -2.38%
===========================================
Files 399 399
Lines 26756 25278 -1478
Branches 1239 1239
===========================================
- Hits 15477 14022 -1455
+ Misses 11279 11256 -23
Continue to review full report at Codecov.
|
image_name=self.tool_definition.image_name, | ||
container_name=self.container_name, | ||
labels={self.uuid: ToolDefinition.VISUALIZATION}, | ||
extra_directories=self.tool_definition.get_extra_directories() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need this? (extra_directories
) @mccalluc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scottx611x : Yes: This is how HiGlass gets a directory for logs that is in the host FS, instead of the limited-capacity union FS.
refinery/tool_manager/models.py
Outdated
|
||
self._django_docker_client.run(container) | ||
|
||
start_container.delay(self) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment here about async
… we provide this info as a url
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine, but I'd want to be sure the async code is not introducing race conditions... Probably fine?
HistoryDatasetElement) | ||
from bioblend.galaxy.dataset_collections import ( | ||
CollectionDescription, CollectionElement, HistoryDatasetElement | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you find the setting to tweak in isort?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah! In an earlier PR: see multi_line_output
|
||
# Pulls docker image if it doesn't exist yet, and launches container | ||
# asynchronously | ||
start_container.delay(self) | ||
return JsonResponse({Tool.TOOL_URL: self.get_relative_container_url()}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was it synchronous before? I worry a little about race conditions... are we sure it will be able to return a container_url no matter where in the launch sequence it is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was before, but now that we have the nice please wait page I think this is okay.
A VisualizationTool will always be able to return its get_relative_container_url()
regardless of the container state.
Without this, one could hit a state where a large docker image hasn't be downloaded yet, and upon clicking launch
the page would seemingly be frozen, while the pending request waits for the image download to complete.
@@ -309,6 +308,7 @@ def create_solr_mock_response(self, nodes): | |||
} | |||
) | |||
|
|||
@override_settings(CELERY_ALWAYS_EAGER=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes me worry a little if the tests depend on Celery...? Particularly since the actual run seems to be mocked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This setting runs Celery on a single thread so that we don't have to worry about sleeping/waiting after launching a Tool in these tests. I could probably mock the underlying delay()
call but this seemed easier.
self.assertEqual(get_response.status_code, 400) | ||
self.assertIn("Couldn't retrieve VisualizationTool", | ||
get_response.content) | ||
self.assertEqual(get_response.status_code, 404) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the underlying error message should still be coming through... but if a 404 doesn't seem appropriate, let me know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we use django.shortcuts.get_object_or_404
a resonable error message is returned. Something like No VisualizationTool matches the given query.
I was hesitant to test Django internals
refinery/tool_manager/views.py
Outdated
@@ -180,7 +182,7 @@ class AutoRelaunchProxy(Proxy, object): | |||
""" | |||
def __init__(self): | |||
super(AutoRelaunchProxy, self).__init__( | |||
settings.DJANGO_DOCKER_ENGINE_DATA_DIR, | |||
None, # TODO: django_docker_engine code should remove need for arg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll look into this. Thanks!
Introduce detail route to
/api/v2/tools/
that returns a launched Tools input data as JSON. This approach (sending a url pointing to a Tool's input data) will be used moving forward for its ease of use w/ a 2nd host running docker. Before, we noticed that there were underlying ssh commands indjango_docker_engine
to create directories on said host to place a launchedVisualizationTool's
input data, and ssh key management between the Refinery EC2 and Docker EC2 was troublesome to automate. This will also prove reusable if we ever need to move to something like ECS or Fargate.TODO:
Note: This shouldn't be merged until we have the 2nd host for docker up and running w/ terraform. See #2597 EDIT: We have the 2nd host working more or less and are just making some final adjustments