-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documenting a known good method for upgrades to upcoming Gluster 4.0 release #22
Comments
@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? |
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 ***@***.***> 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
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGp7mJ6kHXLd-6P9CdqOs1ifPHBeSauVks5tNwv8gaJpZM4Rqvot>
.
--
- Atin (atinm)
|
@csabahenk the topic here is context linked to http://lists.gluster.org/pipermail/gluster-devel/2018-January/054186.html |
Go toolchain can build and compile Go programs on CentOS 6. Go just needs linux to be 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. |
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.)
So (1) is planned and will be tested and documented. (2) needs an additional plan item to get done. |
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. |
|
See, https://docs.gluster.org/en/latest/Upgrade-Guide/upgrade_to_4.0/ for 4.0 upgrade guide. |
Are we at a stage where we can close this out? Is this still relevant? |
CentOS 6 -> 7 was never documented, unsure if that is still relevant though. |
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.
The text was updated successfully, but these errors were encountered: