Draft 1 11/09/2009

 

Abstract: The VistA Kernel Installation & Distribution System (KIDS) is in many ways ahead of its time. Yet automatic updating of Veterans Affairs VistA with little or no human intervention has been a vexing issue. The KIDS system is designed to have updating with human intervention. Automatic updating would be desirable for many reasons. This is a Request for Comment(RFC) for To Operate Your System (TOYS) or KIDS TOYS. KIDS TOYS is a simple, practical convention for automatically (or nearly so) upgrading a VistA server on Unix using bash, here tags, previous conventions promulgated in VistA Standard Base(VSB) (http://astronautvista.com/astronaut-help/manual/vsb-specification) and one new convention for VistA Standard Base(VSB).

Methods

The current VistA Standard Base has the following convention:

/<base_dir>/<branding>vista/<instance>/kids        # KIDs file staging and archiving area.

While useful, it is lacking in a temporal relationship for what was modified between releases as well as a clear one to one correspondence for releases and what is contained in a release. This proposal would further extend it to have /<base_dir>/<branding>vista/<instance>/kids/<point-release-number-subdirectory>  For example, if release 0.8-0 or SP2 may contain a example-video-pack.KIDS and a something-fixed.m file, they would reside in /<base_dir>/<branding>vista/<instance>/kids/SP2 or /<base_dir>/<branding>vista/<instance>/kids/0.8-0 This would provide a organized staging area for either programmatic installation or human readable and human installation while simultaneously providing a history and archive of what the VistA installation contains.

The final convention in this proposal would be the simple use of a TOY file. A TOY file is defined as something that installs its corresponding KIDS or aggregate of KIDS files automatically. Each KIDS file may have a corresponding TOYS file that can be simply a bash script that uses here tags to install its corresponding KIDS file. For example: example-video-pack.TOY which would reside in /<base_dir>/<branding>vista/<instance>/kids/0.8-0 alongside its corresponding example-video-pack.KIDS file. It is possible then to have a aggregate toy file for example: 0.8-0.TOY residing in /<base_dir>/<branding>vista/<instance>/kids/<point-release-number-subdirectory> that simply runs all of the individual TOY files in the order necessary to install them.

Results

This has been tried with some success.  An example TOY file with a corresponding KIDS file is as follows:

#!/bin/bash
# KIDS toy file for: bmx0210.k.WV
#
KIDS_FILE="bmx0210.k.WV"
INSTALL_NAME="BMX 2.1"
source ../bin/env

# PUT THE KIDS RESPONSES HERE FOR LOADING.
$gtm_path/mumps -direct <<EOF
S DUZ=14
D ^XPDIL
$vista_path/kid/$KIDS_FILE
YES


h
EOF
sleep 1
# PUT THE KIDS RESPONSES HERE FOR INSTALLING.
$gtm_path/mumps -direct <<EOF
S DUZ=14
D ^XPDI
$INSTALL_NAME



NULL

h
EOF

Discussion

This is not intended to be an exhaustive or finesse solution. It is intended to be a practical solution that works.  It needs to be tested on a large scale with many patches to make sure that it works.  This method suffers from some limitations such as its one way nature of getting KIDS patches into a system but is silent on removing them. Creating TOY files can be tedious and does not occur in an automated way. Error checking must be done in advance by a person and errors in actual practice may go un-detected.

Conclusions

This is a practical and viable method of organizing and pro-grammatically upgrading VistA while providing a temporal relationship, archive and history.