Documenting a known good method for upgrades to upcoming Gluster 4.0 release

[sankarshanmukhopadhyay]

The upcoming release of Gluster 4.0 would require the users to upgrade systems from a possible set of 3.x series. It would be ideal to put together a matrix of the combination of client and server which lend themselves to easy upgrade. This matrix can be included in the documentation notes/section specifically pertaining to an upgrade.

Additionally, with the declared intent to discontinue the server RPMs for CentOS6 (due to Golang programming language run-time unavailability), it is likely that users would seek to standardize their operating infrastructures on a CentOS7 based deployment. Thus, a known good method or, a process that has been qualified would be needed for documentation.

[csabahenk]

@sankarshan, in what way are we concerned about Golang run-time availability on CentOS6? Binaries created from Golang source are usually static or dynamically link to some C libraries (as the case is with glusterd2 / glustercli, with all those libs shipped by glibc), and there is no specific "Golang run-time". So glusterd2 could be deployed on CentOS6, with no dependency beyond glibc.

Are you maybe thinking of the issue of not being able to build it on CentOS6 in a sanctioned manner due to the lack of a packaged Golang toolchain there? If yes, is it really a show stopper?

[atinmu]

CentOS6 doesn’t have a golang compiler. We can not build or run CI for GD2 which is a hard requirement for 4.0.

On Wed, 24 Jan 2018 at 16:24, Csaba Henk notifications@github.com wrote:

@sankarshan https://github.com/sankarshan, in what way are we concerned about Golang run-time availability on CentOS6? Binaries created from Golang source are usually static or dynamically link to some C libraries (as the case is with glusterd2 / glustercli, with all those libs shipped by glibc), and there is no specific "Golang run-time". So glusterd2 could be deployed on CentOS6, with no dependency beyond glibc.

Are you maybe thinking of the issue of not being able to build it on CentOS6 in a sanctioned manner due to the lack of a packaged Golang toolchain there? If yes, is it really a show stopper?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gluster/community/issues/22#issuecomment-360094314, or mute the thread https://github.com/notifications/unsubscribe-auth/AGp7mJ6kHXLd-6P9CdqOs1ifPHBeSauVks5tNwv8gaJpZM4Rqvot .

--

• Atin (atinm)

[sankarshanmukhopadhyay]

@csabahenk the topic here is context linked to http://lists.gluster.org/pipermail/gluster-devel/2018-January/054186.html

[prashanthpai]

Go toolchain can build and compile Go programs on CentOS 6. Go just needs linux to be >2.6.23

However, the Go compiler isn't available on standard repositories (not EPEL) as RPM. It's available as binaries for download and as source to be compiled.

I cannot think of any technical limitation for running go programs on CentOS 6.

[ShyamsundarR]

1) Upgrade: Typically (rolling) upgrade, is tested from current branches under long term maintenance to the upcoming branch. So, this means we would verify, 3.10/3.12 -> 4.0 upgrades

What the above also means (as our upgrade procedure is servers first and clients next), that clients of the stated versions will work with 4.0 servers. This has to be true anyway as there are processes on the servers that act as a client (self heal, rebalance, quota, etc.)

2) Upgrade from CentOS6 to CentOS7, or upgrade of an OS that does not support in-place upgrades, is something we need to document. This is important for the current release, as per our statement. So what is needed is a chapter/section in the docs on "Replacing nodes, retaining gluster backed storage", or similar.

So (1) is planned and will be tested and documented. (2) needs an additional plan item to get done.

[sankarshanmukhopadhyay]

I fear we are digressing a bit from the main topic. @ShyamsundarR posted an intended plan of action (or, perhaps a statement of fact) to the list. The link is above. Purely on the context of that declaration, it is required to provide the community of users a complete and friction-free end-to-end experience that allows both teams of administrators (app nodes using clients; server nodes) plan for a good upgrade deployment experience.

[ShyamsundarR]

• [x] Upgrade guide from 3.x (maintained versions) to 4.0
• [ ] Upgrading host OS guide for moving from (say) CentOS6 -> CentOS7

[ShyamsundarR]

See, https://docs.gluster.org/en/latest/Upgrade-Guide/upgrade_to_4.0/ for 4.0 upgrade guide.

[sankarshanmukhopadhyay]

Are we at a stage where we can close this out? Is this still relevant?

[ShyamsundarR]

CentOS 6 -> 7 was never documented, unsure if that is still relevant though.