Re: Review Request 34427: AppC provisioner backend using bind mounts.

2015-08-03 Thread Jiang Yan Xu


 On May 21, 2015, 12:29 p.m., Timothy Chen wrote:
  src/slave/containerizer/provisioners/appc/bind_backend.hpp, line 70
  https://reviews.apache.org/r/34427/diff/1/?file=964174#file964174line70
 
  Should we make rootfs a constant somewhere?

Yeah, I think there should be a paths.hpp utility to do all path-related work.


- Jiang Yan


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


On June 22, 2015, 9:53 a.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34427/
 ---
 
 (Updated June 22, 2015, 9:53 a.m.)
 
 
 Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Note: This is a specialized backend; see notes in bind_backend.hpp.
  
 Reproduced here for your convenience:
 
 This is a specialized backend that may be useful for deployments
 using large (multi-GB) single-layer images *and* where more
 recent kernel features such as overlayfs are not available. For small
 images (10's to 100's of MB) the Copy backend may be sufficient.
 1) It supports only a single layer. Multi-layer images will fail
to provision and the container will fail to launch!
 2) The filesystem is read-only because all containers using this
image share the source. Select writable areas can be achieved
by
mounting read-write volumes to places like /tmp, /var/tmp,
/home, etc. using the ContainerInfo. These can be relative to
the executor work directory.
 3) It relies on the image persisting in the store.
 4) It's fast because the bind mount requires (nearly) zero IO.
 
 
 Diffs
 -
 
   src/Makefile.am e7de0f3d1a5efeaef47d5074defe3b40db94f573 
   src/slave/containerizer/provisioners/appc/backend.cpp PRE-CREATION 
   src/slave/containerizer/provisioners/appc/bind_backend.hpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/34427/diff/
 
 
 Testing
 ---
 
 manual testing of a single layer image with RW relative bind mount for /tmp.
 
 
 Thanks,
 
 Ian Downes
 




Re: Review Request 34427: AppC provisioner backend using bind mounts.

2015-07-02 Thread Timothy Chen

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

Ship it!


Ship It!


src/slave/containerizer/provisioners/appc/bind_backend.hpp (line 31)
https://reviews.apache.org/r/34427/#comment143207

Even with overlayfs is available, I don't think users has a choice to use 
it yet.
Perhaps we should give this advice when we have overlayfs backend.


- Timothy Chen


On June 22, 2015, 4:53 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34427/
 ---
 
 (Updated June 22, 2015, 4:53 p.m.)
 
 
 Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Note: This is a specialized backend; see notes in bind_backend.hpp.
  
 Reproduced here for your convenience:
 
 This is a specialized backend that may be useful for deployments
 using large (multi-GB) single-layer images *and* where more
 recent kernel features such as overlayfs are not available. For small
 images (10's to 100's of MB) the Copy backend may be sufficient.
 1) It supports only a single layer. Multi-layer images will fail
to provision and the container will fail to launch!
 2) The filesystem is read-only because all containers using this
image share the source. Select writable areas can be achieved
by
mounting read-write volumes to places like /tmp, /var/tmp,
/home, etc. using the ContainerInfo. These can be relative to
the executor work directory.
 3) It relies on the image persisting in the store.
 4) It's fast because the bind mount requires (nearly) zero IO.
 
 
 Diffs
 -
 
   src/Makefile.am e7de0f3d1a5efeaef47d5074defe3b40db94f573 
   src/slave/containerizer/provisioners/appc/backend.cpp PRE-CREATION 
   src/slave/containerizer/provisioners/appc/bind_backend.hpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/34427/diff/
 
 
 Testing
 ---
 
 manual testing of a single layer image with RW relative bind mount for /tmp.
 
 
 Thanks,
 
 Ian Downes
 




Re: Review Request 34427: AppC provisioner backend using bind mounts.

2015-06-21 Thread Ian Downes


 On May 21, 2015, 12:29 p.m., Timothy Chen wrote:
  src/slave/containerizer/provisioners/appc/bind_backend.hpp, line 60
  https://reviews.apache.org/r/34427/diff/1/?file=964174#file964174line60
 
  I think we typcically add namespaces in cpp files to avoid process:: 
  and std:: everywhere, just a nit.

This is currently header-only. Will correct if moved to source.


- Ian


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


On May 19, 2015, 11:46 a.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34427/
 ---
 
 (Updated May 19, 2015, 11:46 a.m.)
 
 
 Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Note: This is a specialized backend; see notes in bind_backend.hpp.
  
 Reproduced here for your convenience:
 
 This is a specialized backend that may be useful for deployments
 using large (multi-GB) single-layer images *and* where more
 recent kernel features such as overlayfs are not available. For small
 images (10's to 100's of MB) the Copy backend may be sufficient.
 1) It supports only a single layer. Multi-layer images will fail
to provision and the container will fail to launch!
 2) The filesystem is read-only because all containers using this
image share the source. Select writable areas can be achieved
by
mounting read-write volumes to places like /tmp, /var/tmp,
/home, etc. using the ContainerInfo. These can be relative to
the executor work directory.
 3) It relies on the image persisting in the store.
 4) It's fast because the bind mount requires (nearly) zero IO.
 
 
 Diffs
 -
 
   src/Makefile.am 34755cf795391c9b8051a5e4acc6caf844984496 
   src/slave/containerizer/provisioners/appc/backend.cpp PRE-CREATION 
   src/slave/containerizer/provisioners/appc/bind_backend.hpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/34427/diff/
 
 
 Testing
 ---
 
 manual testing of a single layer image with RW relative bind mount for /tmp.
 
 
 Thanks,
 
 Ian Downes
 




Re: Review Request 34427: AppC provisioner backend using bind mounts.

2015-06-15 Thread Till Toenshoff

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



src/slave/containerizer/provisioners/appc/bind_backend.hpp
https://reviews.apache.org/r/34427/#comment140424

Given that you dont declare any templates, would it make sense to split 
this into cpp+hpp?



src/slave/containerizer/provisioners/appc/bind_backend.hpp
https://reviews.apache.org/r/34427/#comment140425




- Till Toenshoff


On May 19, 2015, 6:46 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34427/
 ---
 
 (Updated May 19, 2015, 6:46 p.m.)
 
 
 Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Note: This is a specialized backend; see notes in bind_backend.hpp.
  
 Reproduced here for your convenience:
 
 This is a specialized backend that may be useful for deployments
 using large (multi-GB) single-layer images *and* where more
 recent kernel features such as overlayfs are not available. For small
 images (10's to 100's of MB) the Copy backend may be sufficient.
 1) It supports only a single layer. Multi-layer images will fail
to provision and the container will fail to launch!
 2) The filesystem is read-only because all containers using this
image share the source. Select writable areas can be achieved
by
mounting read-write volumes to places like /tmp, /var/tmp,
/home, etc. using the ContainerInfo. These can be relative to
the executor work directory.
 3) It relies on the image persisting in the store.
 4) It's fast because the bind mount requires (nearly) zero IO.
 
 
 Diffs
 -
 
   src/Makefile.am 34755cf795391c9b8051a5e4acc6caf844984496 
   src/slave/containerizer/provisioners/appc/backend.cpp PRE-CREATION 
   src/slave/containerizer/provisioners/appc/bind_backend.hpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/34427/diff/
 
 
 Testing
 ---
 
 manual testing of a single layer image with RW relative bind mount for /tmp.
 
 
 Thanks,
 
 Ian Downes
 




Re: Review Request 34427: AppC provisioner backend using bind mounts.

2015-05-21 Thread Paul Brett

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


LGTM

- Paul Brett


On May 19, 2015, 6:46 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34427/
 ---
 
 (Updated May 19, 2015, 6:46 p.m.)
 
 
 Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Note: This is a specialized backend; see notes in bind_backend.hpp.
  
 Reproduced here for your convenience:
 
 This is a specialized backend that may be useful for deployments
 using large (multi-GB) single-layer images *and* where more
 recent kernel features such as overlayfs are not available. For small
 images (10's to 100's of MB) the Copy backend may be sufficient.
 1) It supports only a single layer. Multi-layer images will fail
to provision and the container will fail to launch!
 2) The filesystem is read-only because all containers using this
image share the source. Select writable areas can be achieved
by
mounting read-write volumes to places like /tmp, /var/tmp,
/home, etc. using the ContainerInfo. These can be relative to
the executor work directory.
 3) It relies on the image persisting in the store.
 4) It's fast because the bind mount requires (nearly) zero IO.
 
 
 Diffs
 -
 
   src/Makefile.am 34755cf795391c9b8051a5e4acc6caf844984496 
   src/slave/containerizer/provisioners/appc/backend.cpp PRE-CREATION 
   src/slave/containerizer/provisioners/appc/bind_backend.hpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/34427/diff/
 
 
 Testing
 ---
 
 manual testing of a single layer image with RW relative bind mount for /tmp.
 
 
 Thanks,
 
 Ian Downes
 




Re: Review Request 34427: AppC provisioner backend using bind mounts.

2015-05-21 Thread Timothy Chen

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



src/slave/containerizer/provisioners/appc/bind_backend.hpp
https://reviews.apache.org/r/34427/#comment136120

How about adding a check that there is also at least one image (empty 
vector)?



src/slave/containerizer/provisioners/appc/bind_backend.hpp
https://reviews.apache.org/r/34427/#comment136121

I think we typcically add namespaces in cpp files to avoid process:: and 
std:: everywhere, just a nit.



src/slave/containerizer/provisioners/appc/bind_backend.hpp
https://reviews.apache.org/r/34427/#comment136122

Should we make rootfs a constant somewhere?


- Timothy Chen


On May 19, 2015, 6:46 p.m., Ian Downes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/34427/
 ---
 
 (Updated May 19, 2015, 6:46 p.m.)
 
 
 Review request for mesos, Chi Zhang, Paul Brett, Timothy Chen, and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Note: This is a specialized backend; see notes in bind_backend.hpp.
  
 Reproduced here for your convenience:
 
 This is a specialized backend that may be useful for deployments
 using large (multi-GB) single-layer images *and* where more
 recent kernel features such as overlayfs are not available. For small
 images (10's to 100's of MB) the Copy backend may be sufficient.
 1) It supports only a single layer. Multi-layer images will fail
to provision and the container will fail to launch!
 2) The filesystem is read-only because all containers using this
image share the source. Select writable areas can be achieved
by
mounting read-write volumes to places like /tmp, /var/tmp,
/home, etc. using the ContainerInfo. These can be relative to
the executor work directory.
 3) It relies on the image persisting in the store.
 4) It's fast because the bind mount requires (nearly) zero IO.
 
 
 Diffs
 -
 
   src/Makefile.am 34755cf795391c9b8051a5e4acc6caf844984496 
   src/slave/containerizer/provisioners/appc/backend.cpp PRE-CREATION 
   src/slave/containerizer/provisioners/appc/bind_backend.hpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/34427/diff/
 
 
 Testing
 ---
 
 manual testing of a single layer image with RW relative bind mount for /tmp.
 
 
 Thanks,
 
 Ian Downes