From 1a8dbb8b93adf1b92f938134def2d66b4a225f49 Mon Sep 17 00:00:00 2001 From: Thomas Schoebel-Theuer Date: Sun, 30 Aug 2020 17:32:13 +0200 Subject: [PATCH] all: release mars0.1astable104 --- ChangeLog | 79 ++++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 67 insertions(+), 12 deletions(-) diff --git a/ChangeLog b/ChangeLog index fbc03969..1b7e9c41 100644 --- a/ChangeLog +++ b/ChangeLog @@ -66,7 +66,7 @@ Release Conventions / Branches / Tagnames including network outages and HumanError(tm) at 1&1 Ionos ShaHoLin. Thus the _component_ SLA of MARS must be much better. - There is always an upgrade path. Simply install the new - version. + version, obeying the below compatibility rules. - Rolling upgrades (temporarily different MARS kernel module versions at primary vs secondary side) are supported. Typically, do "rmmod mars; modprobe mars" at the secondary @@ -74,21 +74,46 @@ Release Conventions / Branches / Tagnames primary side. Or, of course, you may combine it with (typically security- triggered) rolling kernel reboots. - HINT: update marsadm first, before updating the kernel module. + I am putting high effort into maintaining rolling upgrades + of kernel modules. The network protocols are designed to + support this. + - COMPATIBILITY RULES: + Ensure that $marsadm_version >= $module_version. + This is the safe side of your update strategy. + Update marsadm first, before updating the kernel module. This way, the controls for newer features are already in place when the new kernel module is activated (no blind flight). - - marsadm may be upgraded and downgraded independently from kernel - (during operations, best via your favorite package manager). - Of course, no magic will happen: newer features are only - available when newer version of both the userspace tool and - the kernel modules are installed. + Since marsadm is a plain Perl script with _no_ dependencies + from anything else, this is something I can reasonably expect + from users. + REASON: ensuring forever backwards compatibility to stone-aged + marsadm versions would make me ill. I cannot change old versions + anymore, but just provide new versions. I cannot ensure and + test all possible O(n^2) combinations of marsadm versions with + kernel module versions to work eternally for all times when + marsadm would be frozen, or even all O(n^3) combinations of + frozen marsadm with mixed-operations kernel modules. + The development of MARS would be hindered by too old marsadm + versions, since my effort would grow quadratically or + even worse. + Hint: nevertheless, many combinations of old marsadm with newer + kernel module version are working anyway, in particular when + the gap is a small $epsilon. But I cannot guarantee in general. + If you want to violate the above rule, you must test the + combination yourself. - Best practice in bigger installations: first test your upgrade - or downgrade at some test clusters first. I cannot lab-test all - possible O(n^2) combinations of marsadm versions with kernel - module versions, or even all O(n^3) combinations of marsadm - with mixed-operations kernel modules. But I am doing my best - lab-testing some important combinations. + or downgrade at some test clusters first. + If you have a separate pre-live stage, it definitely is + your friend. + - As long as $marsadm_version + $epsilon >= $module_version + remains true (at least "approximately") and has been tested + in pre-live, marsadm may be upgraded and downgraded + independently from kernel, and during operations + (best via your favorite package manager). + Of course, no magic will happen: newer features are only + available when newer versions of both the userspace tool and + the kernel modules are installed. - Please check this ChangeLog for any upgrade / downgrade incompatibility bugs. In case they are detected, they will be fixed. But I cannot retrospectivly change already released @@ -118,6 +143,36 @@ Changelog for series 0.1a: Now stable. Receive mainly fixes. +mars0.1astable104 + * Major fix: marsadm did not obey an abort of certain phased + commands when a single resource argument was given. As a result, + a wrong exit code could be returned in such a case. + * Minor fix: when beta feature logfile digests were disabled + _during_ operations, already existing old logfiles were + not always checked correctly at the secondary, + reporting DefectiveLog (although they were healthy). + Workaround by just enabling again and invalidate. + With the fix, you may now replay the old logfiles :) + * Minor fix: inherent race between join-resource and log-rotate + (unavoidable in the Distributed System) could lead to split brain, + or to hanging replay. Now compensated. + * Minor fix: join-cluster without ssh was sometimes not + updating the local link tree immediately. + * Usability (BETA feature): improved scalability in #hosts. + The below BETA feature warnings apply. + Do not exceed the "officially documented" limits too much. + * Usability: join-resource avoids unnecessary fallback + to ssh / rsync. + IMPORTANT: please update marsadm first, before updating the + kernel module. See the above compatibility rules. + This time the compatibility rules are important. I know that + marsadm < 0.1astable85 does no reliable join-resource anymore, + while combinations with old 0.1astable95 appear to work. There is + no merit in bisecting old marsadm releases, instead of just + fucking update the old userspace script in a controlled manner. + * Usability: more accurate IOPS and friends. + * Several smaller fixes and improvements. + mars0.1astable103 * Major regression from mars0.1astable99: secondary replay could hang unnecessarily due to a cascade of race conditions.