mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Review Request 44029: Fetcher::basename should ignore query strings and fragments.
Date Tue, 01 Mar 2016 16:32:14 GMT


> On Feb. 26, 2016, 1:40 p.m., Bernd Mathiske wrote:
> > There is a more elaborate solution to this problem (https://reviews.apache.org/r/40054),
but it requires a lot of code to implement URL parsing. Until we finalize that, I think the
patch at hand gets the most urgent job done.
> 
> Jiang Yan Xu wrote:
>     The concern here is that it changes the current behavior of the fetcher output. Although
we agree that probably most people would find the query string in the filename annoying, there
could be people who rely on this (and with a workaround in place) and this will suddenly break
things.
>     
>     The explicit output filename proposed in https://issues.apache.org/jira/browse/MESOS-3367
sounds like the right approach.
> 
> Jiang Yan Xu wrote:
>     When we have an alternative approach available to users, it's easier to then come
back and impose a deprecate cycle for the default behavior. What do you think?
> 
> James Peach wrote:
>     Yes, there's definitely compatibility concern (for example, ``http://foo/bar/baz?filename.zip``
would no longer work. After chatting with Yan, maybe it is sufficient to ignore the extension
and just try all the extractors. If it is extractable one of them will succeed. I don't think
there's any compatibility concerns here and we wouldn't need to do a deprecation cycle.
> 
> Jiang Yan Xu wrote:
>     So it occurred to me that here's an edge case:
>     
>     Some executable archieves are in fact zip files, e.g., jar and pex files. In the
past they wouldn't get automatically decompressed due to their suffixes and not that unzip
couldn't decomopress them.
>     
>     The original file is still going to be there but this implicates disk quota, etc.
Seemingly not an extremely dangerous case but probably still warrants a deprecation cycle.
> 
> Bernd Mathiske wrote:
>     @jpeach, are you OK with discarding this approach and going with setting an explicit
name instead? 
>     https://issues.apache.org/jira/browse/MESOS-4735

> Some executable archieves are in fact zip files, e.g., jar and pex files. In the past
they wouldn't get automatically
> decompressed due to their suffixes and not that unzip couldn't decomopress them.

This would still be true, since if you deployed a jar or a pex you would not set the ``extract``
flag.


- James


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44029/#review120864
-----------------------------------------------------------


On Feb. 25, 2016, 6:32 p.m., James Peach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44029/
> -----------------------------------------------------------
> 
> (Updated Feb. 25, 2016, 6:32 p.m.)
> 
> 
> Review request for mesos, Bernd Mathiske, Jie Yu, and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4779
>     https://issues.apache.org/jira/browse/MESOS-4779
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Ignore URL query parameters and fragments when determining this
> base name. This enables the fetcher to subsequently examine the
> file extension and extract archives correctly.
> 
> 
> Diffs
> -----
> 
>   src/slave/containerizer/fetcher.cpp 33dfcade6beb53a5a6dbc41a8f3380f5cb30a161 
>   src/tests/fetcher_tests.cpp fb47706eb90ae5808bafe13c681d609a808b0c8e 
> 
> Diff: https://reviews.apache.org/r/44029/diff/
> 
> 
> Testing
> -------
> 
> ``make check`` on OS X.
> 
> 
> Thanks,
> 
> James Peach
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message