<div dir="ltr">Oh, and yes. make sure to double check the .deb packages pls :) Last time there was a bug, because of what volumes didn't start after upgrade. I know these are made by volunteers, but devs should give them appropriate signals I believe. </div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-15 11:29 GMT+03:00 Mauro M. <span dir="ltr"><<a href="mailto:gluster@ezplanet.net" target="_blank">gluster@ezplanet.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">To date my experience with upgrades has been a disaster in that in two<br>
cases I was unable to start my volume and eventually I had to downgrade.<br>
<br>
What I want to recommend is that there is an EXTENSIVE REGRESSION TEST.<br>
The most important goal is that NOTHING that works with the previous<br>
release should break in the new release.<br>
<br>
I recommend to test in particular with multi-homed bricks, it is to expect<br>
that administrators create fast (Infiniband) LANs dedicated to gluster<br>
with their own separate IPs and Names, physically separated from the LAN<br>
interfaces that carry the canonical host name.<br>
<br>
Make sure as well that file system attributes or configuration files<br>
aren't changed during the upgrade to a point that prevents a safe<br>
downgrade.<br>
<br>
</span><span class="im HOEnZb">Mauro<br>
<br>
On Thu, October 15, 2015 04:14, Atin Mukherjee wrote:<br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> On 10/14/2015 05:50 PM, Roman wrote:<br>
>> Hi,<br>
>><br>
>> Its hard to comment plans and things like these, but I suggest everyone<br>
>> will be happy to have a possibility to upgrade from 3 to 4 without new<br>
>> installation, OK with offline upgrade also (shut down volumes and<br>
>> upgrade). And I'm somehow pretty sure, that this upgrade process should<br>
>> be pretty flawless so no one under any circumstances would need any kind<br>
>> of rollbacks, so there should not be any IFs :)<br>
> Just to clarify that there will be and has to be an upgrade path. That's<br>
> what I mentioned in point 4 in my mail. The only limitation would be<br>
> here is no rolling upgrade support.<br>
>><br>
>> 2015-10-07 8:32 GMT+03:00 Atin Mukherjee <<a href="mailto:amukherj@redhat.com">amukherj@redhat.com</a><br>
>> <mailto:<a href="mailto:amukherj@redhat.com">amukherj@redhat.com</a>>>:<br>
>><br>
>> Hi All,<br>
>><br>
>> Over the course of the design discussion, we got a chance to discuss<br>
>> about the upgrades and backward compatibility strategy for Gluster<br>
>> 4.0<br>
>> and here is what we came up with:<br>
>><br>
>> 1. 4.0 cluster would be separate from 3.x clusters. Heterogeneous<br>
>> support won't be available.<br>
>><br>
>> 2. All CLI interfaces exposed in 3.x would continue to work with<br>
>> 4.x.<br>
>><br>
>> 3. ReSTful APIs for all old & new management actions.<br>
>><br>
>> 4. Upgrade path from 3.x to 4.x would be necessary. We need not<br>
>> support<br>
>> rolling upgrades, however all data layouts from 3.x would need to be<br>
>> honored. Our upgrade path from 3.x to 4.x should not be cumbersome.<br>
>><br>
>><br>
>> Initiative wise upgrades strategy details:<br>
>><br>
>> GlusterD 2.0<br>
>> ------------<br>
>><br>
>> - No rolling upgrade, service disruption is expected<br>
>> - Smooth upgrade from 3.x to 4.x (migration script)<br>
>> - Rollback - If upgrade fails, revert back to 3.x, old configuration<br>
>> data shouldn't be wiped off.<br>
>><br>
>><br>
>> DHT 2.0<br>
>> -------<br>
>> - No in place upgrade to DHT2<br>
>> - Needs migration of data<br>
>> - Backward compat, hence does not exist<br>
>><br>
>> NSR<br>
>> ---<br>
>> - volume migration from AFR to NSR is possible with an offline<br>
>> upgrade<br>
>><br>
>> We would like to hear from the community about your opinion on this<br>
>> strategy.<br>
>><br>
>> Thanks,<br>
>> Atin<br>
>> _______________________________________________<br>
>> Gluster-users mailing list<br>
>> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a> <mailto:<a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>><br>
>> <a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Best regards,<br>
>> Roman.<br>
> _______________________________________________<br>
> Gluster-users mailing list<br>
> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
</div></div><div class="HOEnZb"><div class="h5">> <a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a><br>
><br>
<br>
<br>
--<br>
Mauro Mozzarelli<br>
Phone: <a href="tel:%2B44%207941%20727378" value="+447941727378">+44 7941 727378</a><br>
eMail: <a href="mailto:mauro@ezplanet.net">mauro@ezplanet.net</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best regards,<br>Roman.</div>
</div>