mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Downes" <ian.dow...@gmail.com>
Subject Re: Review Request 34140: AppC image store
Date Sat, 20 Jun 2015 00:30:45 GMT


> On May 27, 2015, 4:10 p.m., Paul Brett wrote:
> > src/slave/containerizer/provisioners/appc/store.cpp, line 138
> > <https://reviews.apache.org/r/34140/diff/1/?file=957277#file957277line138>
> >
> >     And log the error?

This is standard clean up, errors will be logged by any preceeding component if it fails.


> On May 27, 2015, 4:10 p.m., Paul Brett wrote:
> > src/slave/containerizer/provisioners/appc/store.cpp, line 188
> > <https://reviews.apache.org/r/34140/diff/1/?file=957277#file957277line188>
> >
> >     We probably want to keep a track on how long it took so we can debug performance
issues.

IIRC, this is logged by the fetcher.


> On May 27, 2015, 4:10 p.m., Paul Brett wrote:
> > src/slave/containerizer/provisioners/appc/store.cpp, line 259
> > <https://reviews.apache.org/r/34140/diff/1/?file=957277#file957277line259>
> >
> >     Do we cache the hashes?

Cache in what sense? when we fetch something we hash it and store it according to its hash.
We assume that a stored image on the host is not modified but whenever we fetch something
we need to recompute the hash...


> On May 27, 2015, 4:10 p.m., Paul Brett wrote:
> > src/slave/containerizer/provisioners/appc/store.cpp, line 267
> > <https://reviews.apache.org/r/34140/diff/1/?file=957277#file957277line267>
> >
> >     Why not do the decompress, hash & untar as a pipeline to reduce disk usage?

Because we need to hash the (decrypted (uncompressed)) tarball, i.e., an intermediate object,
and because we don't know how it is compressed.


> On May 27, 2015, 4:10 p.m., Paul Brett wrote:
> > src/slave/containerizer/provisioners/appc/store.cpp, line 169
> > <https://reviews.apache.org/r/34140/diff/1/?file=957277#file957277line169>
> >
> >     Does the mesos-fetcher choose the name or is that down to the requester?  Can
we assume that the name is safe to use?  Why not pass it from StoreProcess rather than try
to work it out after the fact?

The fetcher guesses from the basename of the url.


- Ian


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


On May 26, 2015, 11:25 a.m., Ian Downes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/34140/
> -----------------------------------------------------------
> 
> (Updated May 26, 2015, 11:25 a.m.)
> 
> 
> Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Images are fetched into the store (after discovery). Stored images are
> currently kept indefinitely.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am 14bc976a7b6a656fb58085484d25c3de3cf0f693 
>   src/slave/containerizer/provisioners/appc/store.hpp PRE-CREATION 
>   src/slave/containerizer/provisioners/appc/store.cpp PRE-CREATION 
>   src/slave/flags.hpp d3b1ce117fbb4e0b97852ef150b63f35cc991032 
>   src/slave/flags.cpp d0932b04e3825abb6173efe0d1aee199aa356932 
> 
> Diff: https://reviews.apache.org/r/34140/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ian Downes
> 
>


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