[Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

[Roman]

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.

2015-10-15 11:29 GMT+03:00 Mauro M. <gluster at ezplanet.net>:

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


-- 
Best regards,
Roman.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20151015/7ce5efc6/attachment.html>