This is an attempt to respond to several questions in forks of the thread
rooted in this e-mail. Look for [KSB2] below.
On 02/06/2014 09:42 PM (US Eastern Time), Bhaskar, K.S wrote:
On 02/06/2014 09:21 PM (US Eastern Time), Luis Ibanez wrote:
On Thu, Feb 6, 2014 at 3:48 PM, Andreas Tille <[email protected]
<mailto:[email protected]>> wrote:
[KSB2] <...snip...>
I'll bow to Bhaskar on making the case for how many versions is
reasonable to have in the future as we maintain a sliding window
of them.
[KSB] Since a GT.M release is frozen for all time once it's released,
one answer is as many releases as we have disk for. Another answer is
that although we periodically get e-mails from people with five and ten
year old releases, we normally consider releases to have a two year
window of peak use, and maintaining three years' worth is a good
number. That will probably translate to about ten releases.
[KSB2] GT.M users often have multiple GT.M releases installed on their
systems. Here is a representative example: A system hosts the systems
of record for the medical records of both Clinic A and Clinic B. Clinic
A uses release 1 of GT.M, whereas Clinic B uses release 2 of GT.M
(perhaps because Clinic B came online later and used the latest release
of GT.M then available, whereas Clinic A never upgraded). Release 3
becomes available and has new functionality that both clinics want. Here
is an upgrade scenario:
* Set up replica of the production database of Clinic A with GT.M
release 3 and real-time replication from the current instances to the
new instance (so that if a patient record is updated on the Clinic A
system of record in GT.M release 1, it shows up right away also in
the replica using release 3). The replica of Clinic A is created by
taking a backup of the release 1 instance and upgrading it - no
dump/restore is required. Also, the two instances can share the same
source code for the routines of Clinic A, but the object code for the
same source code is different for each release.
* Once satisfied that the replica of Clinic A on release 3 is stable,
at convenient time, switch over so that the system of record on
release 3 is replicating to the system of record on release 1. The
switchover itself can be scripted and executes in seconds. After the
switchover, in the event Clinic A on release 3 has issues, a simple
switchover reverts Clinic A production to release 1.
* Once satisfied that Clinic A on release 3 is stable, shut down
replication to the release 1 instance, and eventually delete it.
* Upgrade Clinic B the same way.
In this representative scenario, there are three GT.M releases
concurrently installed and in use on the system, with no change to the OS
version.
As there is not a reliable way to automatically ensure that a GT.M
release is no longer in use, we strongly recommend that a new GT.M
release always be installed in a new directory. This is analogous to the
Linux kernel, where a new kernel is never installed on top of an old
kernel: once the new kernel is booted, the old kernel can be removed. In
the case of GT.M, even a reboot does not guarantee that a prior release
is no longer needed because a database may have been shutdown cleanly,
and will require a utility program from the release it was opened with to
run it down (this is part of the protection to prevent a database file
from being concurrently opened by multiple nodes).
Because bugs in GT.M are very infrequently encountered in production,
upgrades are rare, and usually only when people want to use new
functionality (since GT.M is under active development, there is new
functionality released frequently).
So, sites would never pin GT.M releases.
Apropos the hard links issues, they are legitimate. The hard links are
security related hard-links between a sub-directory and a parent
directory. The subdirectory is created as part of the GT.M installation
and is thus never on a different filesystem. Please do not replace them
with soft-links, and instead flag them as legitimate.
I think I have responded to all the points raised. If I missed any,
please let me know. Thank you.
Regards
-- Bhaskar
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
