Re: Updating fis-gtm package to 6.1

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

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 <andreas@an3as.eu> 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.