Skip to content
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

Don't validate http preloads locally #3768

Merged
merged 3 commits into from
May 5, 2020

Conversation

necaris
Copy link
Contributor

@necaris necaris commented May 4, 2020

validate_preload_argv can't validate web address preloads for
click.Command compliance, so it shouldn't try.

`validate_preload_argv` can't validate web address preloads for
`click.Command` compliance, so it shouldn't try.
@necaris necaris changed the title Don't valid http preloads locally Don't validate http preloads locally May 4, 2020
Copy link
Member

@jrbourbeau jrbourbeau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @necaris! Just for my own understanding, is the issue here that at the time the validation code is run, we haven't yet downloaded and parsed the remote module into a ModuleType object yet? Is this something that would be straightforward to test?

@necaris
Copy link
Contributor Author

necaris commented May 4, 2020

@jrbourbeau yes, that's basically the issue: because validate_preload_argv is run as a callback when click parses command-line arguments, all of the other processing (including downloading the remote module, etc) hasn't run yet.

I presume that this could be tested by something along the lines of https://github.com/dask/distributed/blob/master/distributed/cli/tests/test_dask_scheduler.py#L269 -- does that seem like the right approach?

@mrocklin
Copy link
Member

mrocklin commented May 4, 2020

is the issue here that at the time the validation code is run, we haven't yet downloaded and parsed the remote module into a ModuleType object yet?

Yes. We're using tornado's AsyncHTTPClient to download the module, and at the point where we validate we haven't yet spun up the event loop, and we're not in an asynchronous context. There are other inconsistencies with web-based preloads. In particular we don't import the module at setup time, but rather at start time.

This is more-or-less necessary if we want to make it easy to test web-based preloads in an asynchronous context (which I think that we do). I think that testability is more important here than the feature mismatch. I'm inclined to wait for a user to arrive before we bend too much to make this fully consistent.

Uses an arbitrary (hardcoded) local port and runs a separate Python
process to serve that on localhost, then uses that address as the target
of the `dask-scheduler` `--preload` option.
@necaris
Copy link
Contributor Author

necaris commented May 4, 2020

@jrbourbeau @mrocklin added 5b8c526 -- please let me know if that's a sensible testing approach.

The scheduler_info.py module isn't around in the local directory
It's only in memory.

As a result we switch up the test a little

Also we now use the tmpdir fixture rather than create tmp files with
context managers
@mrocklin
Copy link
Member

mrocklin commented May 5, 2020

I've modified it a bit. I'm +1 on this and will plan to merge tomorrow if there are no objections.

Copy link
Member

@jrbourbeau jrbourbeau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @necaris @mrocklin, the changes here LGTM. This is in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants