Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-21 Thread Diego Remolina 
I have not quite had such a bad experience with upgrades (was able to
do all upgrades of the 3.5 and 3.6 series without downtime, except for
the 3.6. to 3.7 upgrade where regardless of adding the
rpc-allow-insecure option would not let the 3.7 node talk to the 3.6).
However, had to recently downgrade from 3.7.3 to 3.6.6, and that was a
complete pain because I had to manually change the op-version for all
volumes and for each info file in the vols directory for each of my
volumes. So whatever testing is done to go up to 4.x should take care
of fixing these op-version values in the proper locations if a
rollback is needed.

A shout out to JoeJulian in IRC for all his valuable help in helping
me figure out all the changes needed to go back down to 3.6.x

In case you are wondering why I had to downgrade, then ->
https://bugzilla.redhat.com/show_bug.cgi?id=1234877
which has been confirmed to still occur with 3.7.5.

Diego

On Thu, Oct 15, 2015 at 4:27 AM, Mauro Mozzarelli  wrote:
> One feature I would like to see in 4.0 is to be able to have a volume
> started with only ONE brick up and running, at least as a configurable
> option if not a default.
>
> This was possible in 3.5, perhaps more by mistake than design, but it
> disappeared in 3.6 and it is a major issue if I want to run a second brick
> as standby only.
>
> Right now I can do it in 3.7.4, but if I reboot the single brick I have to
> stop and start again the volume before I can mount it, which is the
> workaround I am using.
>
> 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 >> >:
>>>
>>> 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-us...@gluster.org 
>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Roman.
>> ___
>> Gluster-users mailing list
>> gluster-us...@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>
>
> --
> Mauro Mozzarelli
> Phone: +44 7941 727378
> eMail: ma...@ezplanet.net
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-15 Thread Mauro Mozzarelli 
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 > >:
>>
>> 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-us...@gluster.org 
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>>
>>
>>
>> --
>> Best regards,
>> Roman.
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>


-- 
Mauro Mozzarelli
Phone: +44 7941 727378
eMail: ma...@ezplanet.net

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-15 Thread Mauro Mozzarelli 
One feature I would like to see in 4.0 is to be able to have a volume
started with only ONE brick up and running, at least as a configurable
option if not a default.

This was possible in 3.5, perhaps more by mistake than design, but it
disappeared in 3.6 and it is a major issue if I want to run a second brick
as standby only.

Right now I can do it in 3.7.4, but if I reboot the single brick I have to
stop and start again the volume before I can mount it, which is the
workaround I am using.

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 > >:
>>
>> 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-us...@gluster.org 
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>>
>>
>>
>> --
>> Best regards,
>> Roman.
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>


-- 
Mauro Mozzarelli
Phone: +44 7941 727378
eMail: ma...@ezplanet.net

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-15 Thread Mauro M. 
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 > >:
>>
>> 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-us...@gluster.org 
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>>
>>
>>
>> --
>> Best regards,
>> Roman.
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>


-- 
Mauro Mozzarelli
Phone: +44 7941 727378
eMail: ma...@ezplanet.net

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-15 Thread Mauro M. 
One feature I would like to see in 4.0 is to be able to have a volume
started with only ONE brick up and running, at least as a configurable
option if not a default.

This was possible in 3.5, perhaps more by mistake than design, but it
disappeared in 3.6 and it is a major issue if I want to run a second brick
as standby only.

Right now I can do it in 3.7.4, but if I reboot the single brick I have to
stop and start again the volume before I can mount it, which is the
workaround I am using.

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 > >:
>>
>> 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-us...@gluster.org 
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>>
>>
>>
>> --
>> Best regards,
>> Roman.
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>


-- 
Mauro Mozzarelli
Phone: +44 7941 727378
eMail: ma...@ezplanet.net

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-15 Thread 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. :

> 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  >> >:
> >>
> >> 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-us...@gluster.org 
> >> http://www.gluster.org/mailman/listinfo/gluster-users
> >>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Roman.
> > ___
> > Gluster-users mailing list
> > gluster-us...@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-users
> >
>
>
> --
> Mauro Mozzarelli
> Phone: +44 7941 727378
> eMail: ma...@ezplanet.net
>
>


-- 
Best regards,
Roman.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-14 Thread Atin Mukherjee 


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  >:
> 
> 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-us...@gluster.org 
> http://www.gluster.org/mailman/listinfo/gluster-users
> 
> 
> 
> 
> -- 
> Best regards,
> Roman.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

2015-10-14 Thread Roman 
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 :)

2015-10-07 8:32 GMT+03:00 Atin Mukherjee :

> 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-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>



-- 
Best regards,
Roman.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel