<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 14, 2016 at 4:38 PM, Gandalf Corvotempesta <span dir="ltr"><<a href="mailto:gandalf.corvotempesta@gmail.com" target="_blank">gandalf.corvotempesta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2016-11-14 11:50 GMT+01:00 Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>>:<br>
> To make gluster stable for VM images we had to add all these new features<br>
> and then fix all the bugs Lindsay/Kevin reported. We just fixed a corruption<br>
> issue that can happen with replace-brick which will be available in 3.9.0<br>
> and 3.8.6. The only 2 other known issues that can lead to corruptions are<br>
> add-brick and the bug you filed Gandalf. Krutika just 5 minutes back saw<br>
> something that could possibly lead to the corruption for the add-brick bug.<br>
> Is that really the Root cause? We are not sure yet, we need more time.<br>
> Without Lindsay/Kevin/David Gossage's support this workload would have been<br>
> in much worse condition. These bugs are not easy to re-create thus not easy<br>
> to fix. At least that has been Krutika's experience.<br>
<br>
</span>Ok, but this changes should be placed in a "test" version and not<br>
marked as stable.<br>
I don't see any development release, only stable releases here.<br>
Do you want all features ? Try the "beta/rc/unstable/alpha/dev" version.<br>
Do you want the stable version without known bugs but slow on VMs<br>
workload? Use the "-stable" version.<br>
<br>
If you relase as stable, users tend to upgrade their cluster and use<br>
the newer feature (that you are marking as stable).<br>
What If I upgrade a production cluster to a stable version and try to<br>
add-brick that lead to data corruption ?<br>
I have to restore terabytes worth of data? Gluster is made for<br>
scale-out, what I my cluster was made with 500TB of VMs ?<br>
Try to restore 500TB from a backup....................<br>
<br>
This is unacceptable. add-brick/replace-brick should be common "daily"<br>
operations. You should heavy check these for regression or bug.<br></blockquote><div><br></div><div>This is a very good point. Adding other maintainers.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> One more take away is to get the<br>
> documentation right. Lack of documentation led Alex to try the worst<br>
> possible combo for storing VMs on gluster. So we as community failed in some<br>
> way there as well.<br>
><br>
> Krutika will be sending out VM usecase related documentation after<br>
> 28th of this month. If you have any other feedback, do let us know.<br>
<br>
</span>Yes, lack of updated docs or a reference architecture is a big issue.<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>