[
https://issues.apache.org/jira/browse/MESOS-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu updated MESOS-5776:
--------------------------
Description:
The goal is to implement this interface:
{code}
Future<ImageInfo> get(const Image& image);
{code}
Where `ImageInfo` contains a vector of image layers which will be used by
provisioner to assemble the rootfs for the container. For CVMFS, we have to use
a mount based backend to fully leverage the on-demand fetching capability.
However, it's unclear if CVMFS fuse driver is compatible with overlayfs (or
aufs), we should assume a bind backend. Because of that, the `get` function
above should only return one layer. Also, the provisioned rootfs will be
readonly. In the future, if we found that CVMFS fuse driver is compatible with
overlay filesystems, we can relax this restriction (the rootfs can be writable).
Another tricky thing is that we need to make sure CVMFS is mounted properly.
CVMFS leverage autofs to do auto mounting and will unmount if it detects no
activity. We should either document how CVMFS should be configured, or use some
way in the code to address that.
Another thing to think about is that if the user requests a repository that is
not mounted, the Store needs to make sure it's properly mounted before
returning.
was:
The goal is to implement this interface:
{code}
Future<ImageInfo> get(const Image& image);
{code}
Where `ImageInfo` contains a vector of image layers which will be used by
provisioner to assemble the rootfs for the container. For CVMFS, we have to use
a mount based backend to fully leverage the on-demand fetching capability.
However, it's unclear if CVMFS fuse driver is compatible with overlayfs (or
aufs), we should assume a bind backend. Because of that, the `get` function
above should only return one layer. Also, the provisioned rootfs will be
readonly. In the future, if we found that CVMFS fuse driver is compatible with
overlay filesystems, we can relax this restriction (the rootfs can be writable).
Another tricky thing is that we need to make sure CVMFS is mounted properly.
CVMFS leverage autofs to do auto mounting and will unmount if it detects no
activity. We should either document how CVMFS should be configured, or use some
way in the code to address that.
> Add CVMFS provisioner store.
> ----------------------------
>
> Key: MESOS-5776
> URL: https://issues.apache.org/jira/browse/MESOS-5776
> Project: Mesos
> Issue Type: Task
> Reporter: Jie Yu
>
> The goal is to implement this interface:
> {code}
> Future<ImageInfo> get(const Image& image);
> {code}
> Where `ImageInfo` contains a vector of image layers which will be used by
> provisioner to assemble the rootfs for the container. For CVMFS, we have to
> use a mount based backend to fully leverage the on-demand fetching
> capability. However, it's unclear if CVMFS fuse driver is compatible with
> overlayfs (or aufs), we should assume a bind backend. Because of that, the
> `get` function above should only return one layer. Also, the provisioned
> rootfs will be readonly. In the future, if we found that CVMFS fuse driver is
> compatible with overlay filesystems, we can relax this restriction (the
> rootfs can be writable).
> Another tricky thing is that we need to make sure CVMFS is mounted properly.
> CVMFS leverage autofs to do auto mounting and will unmount if it detects no
> activity. We should either document how CVMFS should be configured, or use
> some way in the code to address that.
> Another thing to think about is that if the user requests a repository that
> is not mounted, the Store needs to make sure it's properly mounted before
> returning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
