You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Jie Yu (JIRA)" <ji...@apache.org> on 2016/07/03 18:38:10 UTC
[jira] [Updated] (MESOS-5776) Add CVMFS provisioner store.
[ 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)