<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 25, 2012 at 11:52 PM, Michael Chapman <span dir="ltr"><<a href="mailto:michael.chapman@anu.edu.au" target="_blank">michael.chapman@anu.edu.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><div><span style="color:rgb(51,51,255)">I'm interested if folks that have expressed the desire for NFS support have looked at what was introduced in Folsom?</span></div>
</div><div>I wasn't even aware it existed. I've looked at it for about 5 minutes so this may be off the mark, but it appears to be making a file on an nfs share and then exposing that as a block device. If that's correct, then it's orthogonal to the use cases presented in this thread.</div>
<div class="im">
<div><br></div><div><span style="font-size:13px;font-family:arial,sans-serif"><font color="#3333ff">Also I'd like to know if there's any way that it could be improved/enhanced to better fit their needs?</font></span></div>
</div><div>There are several features that are being examined here that I can see:</div><div><br></div><div>1. Integrating with an existing distributed filesystem such as GPFS, cxfs or Lustre. In this case I think the driver would be pointed at a directory, and subfolders of that directory are then exported to VMs via NFS. This isn't possible with any of the existing drivers, but wouldn't be difficult to add to the new netapp NFS one.</div>
<div>2. Allowing VMs to share a filesystem. This can be done by mounting a block device through Cinder and then running NFS on top of it, but there's both a performance overhead and a management overhead for users there. This appears to be what the new NFS drivers accomplish by exporting slices of LVM or slices of a netapp appliance.</div>
<div>3. Using an existing NFS appliance to serve block device volumes. This is addressed by the Folsom NFS driver from what I can tell.</div><div class="im"><div><br></div><div><span style="font-size:13px;font-family:arial,sans-serif"><font color="#3333ff">I'd be more interested in going with option 1 at least for Grizzly, and then depending on the participation and feed-back we could decide that it's not enough and we need to do option 2 for the F release</font></span></div>
</div><div>Do you mean the H release?</div><span class=""><font color="#888888"><div><br></div><div> - Michael</div></font></span><div><div><div class="h5"><br><br><div class="gmail_quote">On Sun, Nov 25, 2012 at 6:26 AM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div>On Thu, Nov 22, 2012 at 12:29 AM, Blair Bethwaite <span dir="ltr"><<a href="mailto:blair.bethwaite@gmail.com" target="_blank">blair.bethwaite@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>(Apologies if this doesn't format well - I copied and pasted from the HTML archive as I haven't received the associated digest yet.)<br>
<br>Hi Trey,<br><br>On Thu Nov 22 03:33:20 UTC 2012, "Trey Duskin" <trey at <a href="http://maldivica.com" target="_blank">maldivica.com</a>> wrote:<br>
> Forgive the ignorant question, but why is Cinder the only option for the<br>> backing for "file system as a service" when there is also Swift? The<br>> blueprint that Netapp wrote up for this mentioned Swift would not be<br>
> suitable, but did not explain why.<br><br>I don't think they made that thinking very clear in the blueprint, but I understand where they are coming from, and Michael Chapman already summed it up nicely:<br>"block storage and network shares are both instances of granting individual VMs access to slices of storage resources, and as such belong under a single project". Object storage is fundamentally different because it is a model that has evolved specifically to cater for content download/upload over the Internet, as opposed to storage access within a cloud deployment. Additionally, when you start thinking about the API operations you'd want for volumes and shares you start to see a lot of similarities, not so much for object storage.<br>
<br>> I don't know much about the Cinder<br>> features and limitations, but in the use case of sharing and persisting<br>> large datasets among compute instances, it seems to me Swift would provide<br>> the needed scalability and durability.<br>
<br>It doesn't...<div><br></div><div>It certainly does provide scalability and durability for persisting large datasets - you can tar things up and use it like a tape backup - but only for applications that understand or can easily be made to understand object storage.<br>
<br>It does sharing in part, but not efficiently and certainly nothing like a file-system based share which multiple clients can coordinate on.</div><div><br></div><div>To illustrate, here are a couple of use-cases we want to be able to fulfil which we can't (without serious back-injury as a result of jumping through hoops...) at the moment:</div>
<div>* Run an _existing_ Apache site from a guest that serves mostly static content with occasional changes (seems great for Swift right, except...), where the content is largely file-based hierarchical datasets currently sitting on a HSM system and too large to fit into the available ephemeral disks or volumes.</div>
<div>* Host visualisation services/desktop for large datasets produced on a local HPC facility and sitting on its' GPFS. This requires much better bandwidth and latency than we can get using sshfs or NFS into the guest, attempting to do it over HTTP with Swift isn't going to get us that.<br>
<br>--<br>Cheers,<br>~Blairo<br></div>
<br></div></div><div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></div></blockquote></div><br></div><div class="gmail_extra">Hey Everyone,</div><div class="gmail_extra"><br></div><div class="gmail_extra">So first off, the question is not whether NAS functionality is useful or something that some folks would like to have. The question really is whether it belongs in Cinder or not, my stance has been no, however I think if we have enough interest and we have folks that want to implement and support it then we can move forward and see how things go.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">One question I have is whether or not anybody has looked at the NFS "adapter" that was already added in Folsom? It seems that it might actually address at least some of the needs that have been raised here? To be honest I had hoped to use that as a guage for real interest/demand for NAS support and I haven't seen any mention of it anywhere (patches, bugs, tests, questions etc).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Going forward, I have some concerns about the patch and the approach that's being taken to implement this currently. Maybe they're unwarranted, but I am concerned about mixing in NAS api, manager and rpc in to the existing volume code. It seems we could organize this better and save some confusion and quite frankly maintenance head-ache if we went about this a bit differently. I'm also curious about intent on how this is gated and tested? </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The way I see it there are a couple possible approaches that can be taken on this:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1. Continue with the NFS driver approach that we started on:</div>
<div class="gmail_extra">This isn't the greatest option in terms of feature sets, however I think with a bit more attention and feed-back from folks this could be viable. The concept would be that we abstract out the NAS specifics in the driver, and from the perspective of the API and the rest of the Cinder project we just treat at as a volume as we do with everything else today. To improve upon what's there today, some of the first steps would be creating a new connection type, and there would be some work needed on the Nova side to consume a Network Share. I think this can be done fairly cleanly, it doesn't solve the testing problems, but on the other hand it doesn't touch as much of the core Cinder code so some of my concerns there are addressed.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">2. Go all out with NAS support in Cinder as a separate service:</div><div class="gmail_extra">So this is probably the "right" answer, rather than wedge NAS support in to all of the existing Cinder code, the idea would be to make it a separate Cinder service. The nice thing about this is you can run both Block Storage and NAS on the same Cinder node at the same time to deal with gating etc. This would look similar to what Nova-Volume looked like inside of Nova, there would be clear separation in the API's, Managers, Drivers etc. This is a bit more work that option 1, but if there really is a demand for a robust NAS service this would be the way to go about it in my opinion. Not only does it provide a bit of freedom, but it also provides a good architecture for separation if anybody is ever interested in doing the work to start an independent NAS project.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">So, from my perspective I'd be interested in feed-back regarding option 1. I'm interested if folks that have expressed the desire for NFS support have looked at what was introduced in Folsom? Also I'd like to know if there's any way that it could be improved/enhanced to better fit their needs? I'd be more interested in going with option 1 at least for Grizzly, and then depending on the participation and feed-back we could decide that it's not enough and we need to do option 2 for the F release, or perhaps another option altogether may become evident.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">John</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><div class="im">-- <br><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><div><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px">Michael Chapman</span></div>
<div><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><i>Cloud Computing Services</i></span></div><div><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px">ANU Supercomputer Facility<br>
Room 318, Leonard Huxley Building (#56), Mills Road<br>The Australian National University<br>Canberra ACT 0200 Australia</span></div><div><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px">Tel: <i><a href="tel:%2B61%202%206125%C2%A07106" value="+61261257106" target="_blank">+61 2 6125 7106</a></i><br>
Web: <a href="http://nci.org.au" target="_blank">http://nci.org.au</a></span></div></span><br>
</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>>>Do you mean the H release?<br></div><div class="gmail_extra">Yes... sorry, that's the second time in a week I've done that. I do know the alphabet, really. :)</div>