Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On 01/26/2012 05:19 AM, Karsten Hilbert wrote:
Hello Bhaskar,
this is a really helpful explanation. Let me rephrase (and
slightly change) it as to make sure we've understood:
You attest to that VistA is, basically, on big dark BLOB
sitting on the host OS which the host cannot know anything
about ("cannot" in the sense of "it is too hard to teach the
host about the innards of the VistA blob). That may well be
correct. You also attest, that, of course, a VistA package
can drop that BLOB into the system.
I assume the biggest difference between VistA-blob and
host-OS is that VistA never runs on the bare metal while the
host OS does (I'm sure there's one counter-example with some
obscure hardware out there). IOW, VistA "always" *requires*
a host to be present.
Perhaps it is an even better analogy to think of (in this
case) Debian as the host OS running on the bare metal and
VistaA being a VM living and running on top of that ?
For comparison, surely Debian does not know much about a
BSD-VM and sure as hell doesn't try to update software
inside it (let's ignore that BSD *could* run on the bare
metal).
In the following, replace "BSD" for "VistA":
Technically it would surely be *possible* to
- teach Debian about the tools it needs to run
on behalf of the BSD-VM to update that
- mount the BSD-VM
- run the BSD upgrader inside the BSD-VM
This may not be very *realistic*, however.
Another approach would be to drop package management from
BSD and make it rely on the host OS package management.
Possible but not feasible, I fully agree.
[KSB] Let's take the analogy between VistA and a hosted virtual machine a
bit further. Suppose the virtual machine's root file system was booted
off a partition on the host using a copy-on-write virtual disk, or NFS
mounted, or via an iSCSI target. In that case, it is possible to update
virtual machines by making changes at the host. But you cannot make all
changes at the host - some changes will need to be made within the
virtual machines, and you have to know what you are doing. Similarly,
VistA is not an opaque blob. You can make some changes at the host, but
others will need to be made within VistA, and it requires expertise to
know what is correct.
So, what can an upgraded VistA package usefully do ? It can
- make sure there's enough resources for the "next version"
[KSB] I am not sure if this relevant. There are always enough resources,
since the limits are the host filesystem and database.
- provide external backup scripts
[KSB] This is easily done with simple shell scripts.
- provide an improved tool to "create VistA environments"
on my machine
[SKB] Agreed. A VistA Debian package would be a better tool than my
current "SemiVivA" installation packages.
- serve as a reminder to less-inside VistA people telling
us "VistA insider Bhaskar decided that now there's a
useful/important/needed collection of KIDS packages
available which you really should install"
- helpfully download those KIDS packages into a local cache
while I'm still busy doing something else
- tell the VistA-blob/-VM on our machines the following:
/usr/sbin/hey-vista-upgrade-yourself --from=here
which could then run interactively and require my
intervention as needed
That would seem to me a useful level of integration already.
But maybe this is a pipe dream for one reason or another.
[KSB] VistA already has infrastructure to send KIDS packages to
registered recipients via e-mail. Of course, that is a push system,
whereas Debian package management is a pull system (with periodic polling
by the local package manager).
You can update each virtual machine with aptitude and Debian package
updates.
BSD hosting a Debian machine could well do the following
sequence when a new Debian has been released:
check-available-space
download-packages
mount-debian-vm
send-to-debian "update-yourself-and-here's-your-package-cache"
remove-package-cache
This, of course, requires at least some knowledge on what's
inside the VM blob.
after running aptitude. So, you must run aptitude on each virtual
machine individually: you can't run aptitude on your host and update
all your virtual machines in one fell swoop.
But you can run the above sequence on a bunch of VMs.
A Debian package need not "take away" from what VistA
already does or re-create functionality VistA already has.
But it can provide glue and Debian-like access to VistA
functionality.
[KSB] Agreed. We should let VistA do what it does and supplement it
where appropriate.
In my experience, the mechanics of installing VistA are straightforward.
Configuring VistA is a major project because it is a complete ERP system
for a hospital (it even has features for managing inventory, for
example). Over the years, one source of disappointments that I have seen
when people install VistA is the realization that while installing VistA
can be done in minutes, getting it running even for a small practice
takes expertise.
Regards
-- Bhaskar
Karsten
--
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.
Reply to: