mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jiang Yan Xu" <...@jxu.me>
Subject Re: Review Request 37382: Introduced provisioner Backend interface.
Date Fri, 14 Aug 2015 21:49:34 GMT


> On Aug. 14, 2015, 11:15 a.m., Jie Yu wrote:
> > src/slave/containerizer/provisioners/backend.hpp, lines 55-57
> > <https://reviews.apache.org/r/37382/diff/2/?file=1040433#file1040433line55>
> >
> >     Hum, what do yo mean here?
> >     
> >     I think the backend should be container aware. I.e., we should pass in containerid
in 'provision'  and destroy will take a containerid as well.
> >     
> >     There could be multiple rootfs for a container (because image in volumes). When
the container finishes, the provisioner will try to destroy all rootfs provisioned for that
container.
> >     
> >     Thoughts?
> 
> Jiang Yan Xu wrote:
>     This is intended for the image in volumes case but I was trying to not be too explicit
because it's not implemented yet (we should track it with a separate ticket).
>     
>     My comment about 'nested' was incorrect, let me clarify here.
>     
>     The 'caller' is the provisioner. What I had in mind was: each Backend call handles
one image, if `Backend::provision()`s one image and then it should `destroy()` the rootfs
provisioned by one image.
>     
>     Suppose we have such a rootfs dir and each container has multiple rootfses, some
from ContainerInfo::volumnes and one from ContainerInfo::mesos::image but they are stored
side-by-side under <container_id>/<image_type>.
>     
>     ```
>     <--rootfs_dir>
>     |--<container_id>
>        |--<appc>
>           |--<image_id>
>           |--<image_id>
>        |--<docker>
>     ```
>     
>     IMO since LinuxFilesystemIsolatorProcess::cleanup() calls each `Provisioner::destory(containerId)`
(appc|docker), the provisioner can look at the subdir it manages and scan it and call `Backend::destroy(rootfsPath)`
for each image under it.
>     
>     So each `Backend::destroy(rootfsPath)` call destroys one rootfs and there is no `nesting`
under it.
>     Passing `containerId` into Backend isn't as clean as it should be the provisioner
who converts the id into a path and Backends are this dumb thing which only knows paths.
>     
>     More clear?
> 
> Jie Yu wrote:
>     So the directory layout listed above is managed by the provisioner or backend? It
cannot be backend because otherwise that means provisioner needs to know about the layout
used by the backend.
>     
>     So if it's managed by provisioner, the layout should probably be:
>     ```
>     /var/lib/mesos/provisioners/
>         |-- appc/
>               |-- <container_id>
>                      |-- <image1>
>                      |-- <image2>
>         |-- docker/
>               |-- <container_id>
>                      |-- <image3>
>                      |-- <image4>
>     ```
>     
>     So we only allow one backend, or we allow multiple backends (e.g., what if we want
to use bind mount backend for appc but overlayfs backend for docker, or we want to gradually
roll out overlayfs backend so that two backends co-exists for a while)? If the later, how
can we figure out which backend to use when destroying root filesystems?
>     
>     I just want to get the full picture sorted out. We can chat next week.

Note that the above rootfs I mentioned is the result of the Backend either collapsing its
layers or overlay them and in the provisioner's view it's just one entity.

So the backend know about layout within a rootfs (e.g., its knows that a rootfs is "ImageA(a
script) -> ImageB(essential software) ->ImageC(base OS)"); the provisioner knows about
/ manages the direcotry layout of 'rootfs'es but not inside 'rootfs'es (e.g. This container
wants three rootfses, two of which from volumes).

Yeah I agree the interface design requires a full picture of multi-image-per-contain design.
I will jot down my thoughts in a doc and let's chat next week.


- Jiang Yan


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


On Aug. 14, 2015, 10:51 a.m., Jiang Yan Xu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37382/
> -----------------------------------------------------------
> 
> (Updated Aug. 14, 2015, 10:51 a.m.)
> 
> 
> Review request for mesos, Lily Chen, Ian Downes, Jie Yu, and Timothy Chen.
> 
> 
> Bugs: MESOS-2968
>     https://issues.apache.org/jira/browse/MESOS-2968
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The Backend interface is made generic so it can be used by different provisioners. See
[MESOS-2968](https://issues.apache.org/jira/browse/MESOS-2968?focusedCommentId=14652859&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14652859)
for details.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am b5dbdc316cad179cd265bd81900999fab35940b9 
>   src/slave/containerizer/provisioners/backend.hpp PRE-CREATION 
>   src/slave/containerizer/provisioners/backend.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/37382/diff/
> 
> 
> Testing
> -------
> 
> make check.
> 
> 
> Thanks,
> 
> Jiang Yan Xu
> 
>


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