> On Aug. 14, 2015, 6:15 p.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?

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.


- Jie


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


On Aug. 14, 2015, 5:51 p.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, 5:51 p.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
> 
>

Reply via email to