<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> Actually, there's a hidden assumption here that makes this statement not<br>
> necessarily correct for containers.  You're assuming the container has<br>
> to have raw access to the device it's mounting.  For hypervisors, this<br>
> is true, but it doesn't have to be for containers because the mount<br>
> operation is separate from raw read and write so we can allow or deny<br>
> them granularly.</div></div></blockquote><div><br></div><div>I agree that a container does not have to have raw access to a device that it is mounting, but I also believe that the right contract for Cinder support is to expose raw access to those devices into containers. I don't believe that Cinder support should imply an ability to support mounting the arbitrary filesystems that might live on those volumes, just as we do not today require the guest OS on KVM, VMware, or Xen to support mounting any arbitrary filesystem that might live on a Cinder volume.</div>
<div><br></div><div>It might be stretching the contract slightly to say that containers cannot currently support ANY of the potential filesystems we might expect on Cinder volumes, but I really don't think this should be an issue or point of contention.  I'll remind everyone, too, that raw access to volumes (block devices) inside of containers is not a useless exercise. There are valid things one can do with a block device that have nothing to do with the kernel's ability to mount it as a filesystem.</div>
<div><br></div><div>I believe that for the use-case Cinder typically solves for VMs, however, containers folks should be backing a new filesystem-as-a-service API. I'm not yet certain that Manila is the right solution here, but it may be.</div>
<div><br></div><div>Finally, for those that do ultimately want the ability to mount from inside containers, I think it's ultimately possible. There are ways to allow safer mounting inside containers with varying trade-offs. I just don't think it's a necessary part of the Nova+Cinder contract as it pertains to the capability of the guest, not the capability of the hypervisor (in a sense).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Where you could avoid the risk is if the image you're getting from<br>
glance is not in fact a filesystem, but rather a tar.gz of the container<br>
filesystem. Then Nova would simply be extracting the contents of the<br>
tar archive and not accessing an untrusted filessytem image from<br>
glance. IIUC, this is more or less what Docker does.<br>
<div class="im HOEnZb"></div></blockquote></div><div class="gmail_extra"><br></div>Yes, this is what Docker does.<br clear="all"><div><br></div>-- <br><div dir="ltr">Regards,<div>Eric Windisch</div></div>
</div></div>