<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 14, 2013 at 2:47 PM, <a href="mailto:lzy.dev@gmail.com">lzy.dev@gmail.com</a> <span dir="ltr"><<a href="mailto:lzy.dev@gmail.com" target="_blank">lzy.dev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John and all, about shared-volume implementation detail base on the<br>
R/O volume, for now, it seems there are multiple choice for us:<br>
<br>
a. Supporting R/O volume from Nova side. Ask Nova take care R/O volume<br>
attaching but not Cinder, use hypervisors specific method to keep the<br>
volume be attached in read only mode but actually the backend volume<br>
(in cinder) is on R/W mode. It can be implemented as shared-volume<br>
said "introduce a Read Only option that could be specified during<br>
attach". So as we know, this is not a real R/O volume.<br>
<br></blockquote><div>Implementing R/O control here allows Cinder/Nova to maintain unified capabilities across all the back-ends (given that hypervisors support R/O control over volume).  <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

b. Supporting R/O volume from both Cinder and Nova sides. Nova part<br>
just like I mentioned in above 'a' section. And in Cinder part, we can<br>
give a native R/O volume support capability to Cinder, in this case,<br>
Cinder can pass the read-write mode argument to backend<br>
driver/storage, that is the volume can be attached under the "real"<br>
read-only mode. We also have two choices here:<br>
i. Allow client set this "read-only" mode option in volume creating<br>
API calls, and cinder will not allow modify it after the volume<br>
creating.<br></blockquote><div><br>Any use cases for this?  A lot of changes need to be done to achieve this: modification of API; modification of all Cinder back-end drivers.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

ii. Allow client mark a "read-only" flag to a volume on-demand,<br>
(necessary checking is needed, such as an already attached volume will<br>
not allow change its "read-write" mode), client can change volume from<br>
R/O to R/W or reverse as they needed.<br>
<br></blockquote><div>While this option has best flexibility, it implies the most changes required in Cinder.  Doing R/O control on Nova/hypervisor side seems much simpler and cleaner unless there are special use case Nova side control isn't able to fulfill?<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What's your thoughts?<br>
<br>
Thanks,<br>
Zhi Yan<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, May 14, 2013 at 12:09 PM, John Griffith<br>
<<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, May 13, 2013 at 9:47 PM, <a href="mailto:lzy.dev@gmail.com">lzy.dev@gmail.com</a> <<a href="mailto:lzy.dev@gmail.com">lzy.dev@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi, Guys<br>
>><br>
>> Form below link, it seems Xen can support R/O volume attaching also:<br>
>> <a href="http://backdrift.org/xen-disk-hot-add-block-device-howto" target="_blank">http://backdrift.org/xen-disk-hot-add-block-device-howto</a><br>
>><br>
>> "xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain]"<br>
>> the "mode" can be R/O and R/W (r and w).<br>
>><br>
>> Any thoughts? if not I will update the etherpad to adding xen.<br>
>><br>
>> Thanks,<br>
>> Zhi Yan<br>
>><br>
>> On Tue, May 14, 2013 at 2:26 AM, Martin, Kurt Frederick (ESSN Storage<br>
>> MSDU) <<a href="mailto:kurt.f.martin@hp.com">kurt.f.martin@hp.com</a>> wrote:<br>
>> > Thanks Alessandro, I have also updated the etherpad<br>
>> ><br>
>> > (<a href="https://etherpad.openstack.org/summit-havana-cinder-multi-attach-and-ro-volumes" target="_blank">https://etherpad.openstack.org/summit-havana-cinder-multi-attach-and-ro-volumes</a>)<br>
>> > to include the latest findings regarding R/O volumes. It appears that a<br>
>> > number of hypervisors do indeed allow for setting the volumes to read<br>
>> > only.<br>
>> ><br>
>> > Regards,<br>
>> ><br>
>> > Kurt Martin<br>
>> ><br>
>> ><br>
>> ><br>
>> > From: Alessandro Pilotti [mailto:<a href="mailto:ap@pilotti.it">ap@pilotti.it</a>]<br>
>> > Sent: Monday, May 13, 2013 10:46 AM<br>
>> > To: OpenStack Development Mailing List<br>
>> > Subject: Re: [openstack-dev] [cinder] About Read-Only volume support<br>
>> > Importance: High<br>
>> ><br>
>> ><br>
>> ><br>
>> > Hi guys,<br>
>> ><br>
>> ><br>
>> ><br>
>> > "Summit feedback: Not doing R/O volumes due to the limited hypervisor<br>
>> > that can support setting the volume to R/O, currently only KVM has<br>
>> > this capability".<br>
>> ><br>
>> ><br>
>> ><br>
>> > Hyper-V supports mounting R/O iSCSI volumes as well.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Alessandro<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On May 13, 2013, at 13:22 , <a href="mailto:lzy.dev@gmail.com">lzy.dev@gmail.com</a> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > Hi All,<br>
>> ><br>
>> > In<br>
>> ><br>
>> > <a href="https://etherpad.openstack.org/summit-havana-cinder-multi-attach-and-ro-volumes" target="_blank">https://etherpad.openstack.org/summit-havana-cinder-multi-attach-and-ro-volumes</a>,<br>
>> > I saw a comment there:<br>
>> > "Summit feedback: Not doing R/O volumes due to the limited hypervisor<br>
>> > that can support setting the volume to R/O, currently only KVM has<br>
>> > this capability".<br>
>> ><br>
>> > I agree there probably have some troubles cause R/O volumes support<br>
>> > hard to implement.<br>
>> > But maybe since I have not attended the summit, nova and cinder guys<br>
>> > not notice there is a blueprint to plan to implement a cinder backend<br>
>> > driver for glance<br>
>> > (<a href="https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver" target="_blank">https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver</a>, I<br>
>> > proposed), so I consider the R/O volumes support can be implemented<br>
>> > gracefully.<br>
>> > Under the case, the R/O volume stored in cinder will be created as an<br>
>> > image, client can access it by glance via standard api, and nova can<br>
>> > prepare the R/W image (base on R/O volume) for the instance normally.<br>
>> ><br>
>> > And more, I consider the R/O volume support and cinder driver for<br>
>> > glance is valuable  because on nova side we can give some code changes<br>
>> > to allow nova prepare instance disk via particular COW mechanism base<br>
>> > on particular cinder backend store capability with more efficiency<br>
>> > way, such as efficient snapshot.<br>
>> ><br>
>> > Thanks,<br>
>> > Zhi Yan<br>
>> ><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>
>> ><br>
>> ><br>
>> ><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>
>><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>
><br>
> Thanks Zhi Yan, I had some conversations with folks at the summit and the<br>
> general concensus seemed to be that it was possible.  There's a BP for this<br>
> that met a bit of objection:<br>
> <a href="https://blueprints.launchpad.net/cinder/+spec/shared-volume" target="_blank">https://blueprints.launchpad.net/cinder/+spec/shared-volume</a><br>
><br>
> perhaps we can work off of that and add some details to it.<br>
><br>
> Thanks,<br>
> John<br>
><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>
<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Regards<br>Huang Zhiteng
</div></div>