> On Feb. 26, 2016, 5:40 a.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.

@jpeach, are you OK with discarding this approach and going with setting an 
explicit name instead? 
https://issues.apache.org/jira/browse/MESOS-4735


- Bernd


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


On Feb. 25, 2016, 10:32 a.m., James Peach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44029/
> -----------------------------------------------------------
> 
> (Updated Feb. 25, 2016, 10:32 a.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
> 
>

Reply via email to