Request for Comment: Draft 1 Veterans Affairs VistA Upgrade Convention Proposal: KIDS TOYS
4 views
Skip to first unread message
Ignacio Valdes
Nov 9, 2009, 11:09:33 PM11/9/09
to hardhats
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)
proposal 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).
Please use the co-ment system to comment and discuss:
http://astronautvista.com/news/veterans-affairs-vista-upgrade-convention-proposal-kids-toy
-- IV
PS: JLZ, ask and you shall receive (sometimes) :-)
Sam Habiel
Nov 15, 2009, 6:11:42 AM11/15/09
to hard...@googlegroups.com
Igancio,
Kids needs to be rewritten so that it is silent, and so that it
supports various vista entities as primitives on the file system.
The system you propose is just a way to work with status quo. The only
reason this would be practical is if we are dealing with a closed
source product. We are not. We can rewrite kids. Your only obstacle is
getting a good set of programmers to do it. In any case, your system
will work on a limited subset of kids files as kids files are very
talkative.
Sam
PS: Tried logging into your website to place comments with openid;
gave up after 4 attempts. So these are my comments.
> --~--~---------~--~----~------------~-------~--~----~
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats-u...@googlegroups.com
> -~----------~----~----~----~------~----~------~--~---
>
>
Kids needs to be rewritten so that it is silent, and so that it
supports various vista entities as primitives on the file system.
The system you propose is just a way to work with status quo. The only
reason this would be practical is if we are dealing with a closed
source product. We are not. We can rewrite kids. Your only obstacle is
getting a good set of programmers to do it. In any case, your system
will work on a limited subset of kids files as kids files are very
talkative.
Sam
PS: Tried logging into your website to place comments with openid;
gave up after 4 attempts. So these are my comments.
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats-u...@googlegroups.com
> -~----------~----~----~----~------~----~------~--~---
>
>
kdt...@gmail.com
Nov 15, 2009, 7:49:29 AM11/15/09
to Hardhats
What I would like to know, is how the Debian installation system
works. It seems to have a GUI wrapper for a command-line installation
process. You can show the work, or hide it. And occasionally, it
will pop up another GUI for you to answer a command line question.
I don't think we are going to be able to stop KIDS patches from being
able to ask the user questions. But we should be able to make it look
nicer.
Kevin
On Nov 15, 6:11 am, Sam Habiel <sam.hab...@gmail.com> wrote:
> Igancio,
>
> Kids needs to be rewritten so that it is silent, and so that it
> supports various vista entities as primitives on the file system.
>
> The system you propose is just a way to work with status quo. The only
> reason this would be practical is if we are dealing with a closed
> source product. We are not. We can rewrite kids. Your only obstacle is
> getting a good set of programmers to do it. In any case, your system
> will work on a limited subset of kids files as kids files are very
> talkative.
>
> Sam
> PS: Tried logging into your website to place comments with openid;
> gave up after 4 attempts. So these are my comments.
>
works. It seems to have a GUI wrapper for a command-line installation
process. You can show the work, or hide it. And occasionally, it
will pop up another GUI for you to answer a command line question.
I don't think we are going to be able to stop KIDS patches from being
able to ask the user questions. But we should be able to make it look
nicer.
Kevin
On Nov 15, 6:11 am, Sam Habiel <sam.hab...@gmail.com> wrote:
> Igancio,
>
> Kids needs to be rewritten so that it is silent, and so that it
> supports various vista entities as primitives on the file system.
>
> The system you propose is just a way to work with status quo. The only
> reason this would be practical is if we are dealing with a closed
> source product. We are not. We can rewrite kids. Your only obstacle is
> getting a good set of programmers to do it. In any case, your system
> will work on a limited subset of kids files as kids files are very
> talkative.
>
> Sam
> PS: Tried logging into your website to place comments with openid;
> gave up after 4 attempts. So these are my comments.
>
> On Mon, Nov 9, 2009 at 8:09 PM, Ignacio Valdes <ival...@hal-pc.org> wrote:
>
> > 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)
> > proposal 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).
>
> > Please use the co-ment system to comment and discuss:
>
> >http://astronautvista.com/news/veterans-affairs-vista-upgrade-convent...
>
> > 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)
> > proposal 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).
>
> > Please use the co-ment system to comment and discuss:
>
Nancy Anthracite
Nov 15, 2009, 8:16:32 AM11/15/09
to hard...@googlegroups.com, Sam Habiel
There are ways to automate much of the KIDS installations, but there are good
reasons to keep an eye on what is going on and get a human involved in the
installations. Some places need changes that are site specific so some changes
must be manual.
WorldVistA will be distributing multibuilds as a service to make the process
easier but not automatic which will be suitable for those who have pretty
much stuck with the unmodified version of WorldVistA EHR. Otherwise, the one
by one method checking for "collisions" will be needed. The multibuilds,
however, are not what I am referring to as the automatic way of installing
patches. They, too, require monitoring and evaluation and human intervention
to complete the steps necessary to update the database.
--
Nancy Anthracite
reasons to keep an eye on what is going on and get a human involved in the
installations. Some places need changes that are site specific so some changes
must be manual.
WorldVistA will be distributing multibuilds as a service to make the process
easier but not automatic which will be suitable for those who have pretty
much stuck with the unmodified version of WorldVistA EHR. Otherwise, the one
by one method checking for "collisions" will be needed. The multibuilds,
however, are not what I am referring to as the automatic way of installing
patches. They, too, require monitoring and evaluation and human intervention
to complete the steps necessary to update the database.
Nancy Anthracite
I, Valdes
Nov 15, 2009, 1:05:01 PM11/15/09
to Hardhats
Sorry Sam, Try it now from the front page in the blue bar across the
front click Register. -- IV
On Nov 15, 5:11 am, Sam Habiel <sam.hab...@gmail.com> wrote:
> Igancio,
>
> Kids needs to be rewritten so that it is silent, and so that it
> supports various vista entities as primitives on the file system.
>
> The system you propose is just a way to work with status quo. The only
> reason this would be practical is if we are dealing with a closed
> source product. We are not. We can rewrite kids. Your only obstacle is
> getting a good set of programmers to do it. In any case, your system
> will work on a limited subset of kids files as kids files are very
> talkative.
>
> Sam
> PS: Tried logging into your website to place comments with openid;
> gave up after 4 attempts. So these are my comments.
>
front click Register. -- IV
On Nov 15, 5:11 am, Sam Habiel <sam.hab...@gmail.com> wrote:
> Igancio,
>
> Kids needs to be rewritten so that it is silent, and so that it
> supports various vista entities as primitives on the file system.
>
> The system you propose is just a way to work with status quo. The only
> reason this would be practical is if we are dealing with a closed
> source product. We are not. We can rewrite kids. Your only obstacle is
> getting a good set of programmers to do it. In any case, your system
> will work on a limited subset of kids files as kids files are very
> talkative.
>
> Sam
> PS: Tried logging into your website to place comments with openid;
> gave up after 4 attempts. So these are my comments.
>
> On Mon, Nov 9, 2009 at 8:09 PM, Ignacio Valdes <ival...@hal-pc.org> wrote:
>
> > 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)
> > proposal 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).
>
> > Please use the co-ment system to comment and discuss:
>
> >http://astronautvista.com/news/veterans-affairs-vista-upgrade-convent...
>
> > 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)
> > proposal 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).
>
> > Please use the co-ment system to comment and discuss:
>
Butch
Nov 15, 2009, 3:02:37 PM11/15/09
to Hardhats
I've waited to comment on this one, as I'm not all that familiar with
and the normal administrative process of VistA as of yet. So far what
I have seen though, is that it should be treated the same as a
standalone server in any operating environment.
The admin(s) responsible for the systems should always run the
upgrades manually. Another often over looked aspect of this is you
NEVER apply updates directly to your production server. You always
test them on an identical test server, to try and identify any changes
or problems that will occur as part of the update process.
Once you have confirmed that there are no problems with the updates,
and the "normal" operation of the system is reasonably well assured,
then you apply the patches/updates/etc. to your production system.
Even after the updates are applied in production, the system still
needs to be observed to keep an eye out for problems.
I realize that in small installations that this is a challenge, but
it's something that needs to be done, and using some method of
virtualization will help with the process. VirtualBox and VMWare are
probably the simplest methods, though admittedly not the best in the
long term.
--
Butch
On Nov 15, 8:16 am, Nancy Anthracite <nanthrac...@earthlink.net>
wrote:
and the normal administrative process of VistA as of yet. So far what
I have seen though, is that it should be treated the same as a
standalone server in any operating environment.
The admin(s) responsible for the systems should always run the
upgrades manually. Another often over looked aspect of this is you
NEVER apply updates directly to your production server. You always
test them on an identical test server, to try and identify any changes
or problems that will occur as part of the update process.
Once you have confirmed that there are no problems with the updates,
and the "normal" operation of the system is reasonably well assured,
then you apply the patches/updates/etc. to your production system.
Even after the updates are applied in production, the system still
needs to be observed to keep an eye out for problems.
I realize that in small installations that this is a challenge, but
it's something that needs to be done, and using some method of
virtualization will help with the process. VirtualBox and VMWare are
probably the simplest methods, though admittedly not the best in the
long term.
--
Butch
On Nov 15, 8:16 am, Nancy Anthracite <nanthrac...@earthlink.net>
wrote:
> There are ways to automate much of the KIDS installations, but there are good
> reasons to keep an eye on what is going on and get a human involved in the
> installations. Some places need changes that are site specific so some changes
> must be manual.
>
> WorldVistA will be distributing multibuilds as a service to make the process
> easier but not automatic which will be suitable for those who have pretty
> much stuck with the unmodified version of WorldVistA EHR. Otherwise, the one
> by one method checking for "collisions" will be needed. The multibuilds,
> however, are not what I am referring to as the automatic way of installing
> patches. They, too, require monitoring and evaluation and human intervention
> to complete the steps necessary to update the database.
>
> On Sunday 15 November 2009, Sam Habiel wrote:
>
>
>
> > Igancio,
>
> > Kids needs to be rewritten so that it is silent, and so that it
> > supports various vista entities as primitives on the file system.
>
> > The system you propose is just a way to work with status quo. The only
> > reason this would be practical is if we are dealing with a closed
> > source product. We are not. We can rewrite kids. Your only obstacle is
> > getting a good set of programmers to do it. In any case, your system
> > will work on a limited subset of kids files as kids files are very
> > talkative.
>
> > Sam
> > PS: Tried logging into your website to place comments with openid;
> > gave up after 4 attempts. So these are my comments.
>
> reasons to keep an eye on what is going on and get a human involved in the
> installations. Some places need changes that are site specific so some changes
> must be manual.
>
> WorldVistA will be distributing multibuilds as a service to make the process
> easier but not automatic which will be suitable for those who have pretty
> much stuck with the unmodified version of WorldVistA EHR. Otherwise, the one
> by one method checking for "collisions" will be needed. The multibuilds,
> however, are not what I am referring to as the automatic way of installing
> patches. They, too, require monitoring and evaluation and human intervention
> to complete the steps necessary to update the database.
>
> On Sunday 15 November 2009, Sam Habiel wrote:
>
>
>
> > Igancio,
>
> > Kids needs to be rewritten so that it is silent, and so that it
> > supports various vista entities as primitives on the file system.
>
> > The system you propose is just a way to work with status quo. The only
> > reason this would be practical is if we are dealing with a closed
> > source product. We are not. We can rewrite kids. Your only obstacle is
> > getting a good set of programmers to do it. In any case, your system
> > will work on a limited subset of kids files as kids files are very
> > talkative.
>
> > Sam
> > PS: Tried logging into your website to place comments with openid;
> > gave up after 4 attempts. So these are my comments.
>
> > On Mon, Nov 9, 2009 at 8:09 PM, Ignacio Valdes <ival...@hal-pc.org> wrote:
> > > 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)
> > > proposal 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).
>
> > > Please use the co-ment system to comment and discuss:
>
> > >http://astronautvista.com/news/veterans-affairs-vista-upgrade-convent...
> > > 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)
> > > proposal 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).
>
> > > Please use the co-ment system to comment and discuss:
>
George Timson
Nov 15, 2009, 3:10:04 PM11/15/09
to Hardhats
FWIW, in the Medsphere OpenVista distribtution, you can find a routine
that I wrote called MSCXPDIL. I haven't looked at it for several
years, but it was intended to do what KIDS' "LOAD A DISTRIBUTION"
Option does, silently.
--George Timson
that I wrote called MSCXPDIL. I haven't looked at it for several
years, but it was intended to do what KIDS' "LOAD A DISTRIBUTION"
Option does, silently.
--George Timson
kdt...@gmail.com
Nov 15, 2009, 3:50:51 PM11/15/09
to Hardhats
Bravo!
Kevin
Kevin
Jason Hernandez
Nov 17, 2009, 1:08:09 AM11/17/09
to Hardhats
The Debian package management system does the following, from a top-
down view:
Synaptic / other installer GUI / Aptitude ncurses interface:
Provides a graphical display of packages, descriptions,
dependencies
Calls on apt-get to download packages, manage dependencies, and
install
Apt-get:
Checks dependencies, downloads necessary packages, calls on
dpkg to
install packages
Dpkg:
Processes packages individually, checks dependencies and
installs
files. If dpkg notices an error (files to be overwitten,
missing
dependencies) it returns an error message and does not
install or
configure the package depending on the severity of the
conflict
Those configuration questions that you come across on Debian systems
are run
through debconf:
http://en.wikipedia.org/wiki/Debconf_(software_package)
Debconf just passes the questions the install script has to whatever
front end you
use. I've only done a few KIDS installs, but it looks like one could
ask the install
questions through debconf and pass them onto KIDS.
I'm interested in working on this. I'm going to look up the proposal
and write up any comments.
~Jason
down view:
Synaptic / other installer GUI / Aptitude ncurses interface:
Provides a graphical display of packages, descriptions,
dependencies
Calls on apt-get to download packages, manage dependencies, and
install
Apt-get:
Checks dependencies, downloads necessary packages, calls on
dpkg to
install packages
Dpkg:
Processes packages individually, checks dependencies and
installs
files. If dpkg notices an error (files to be overwitten,
missing
dependencies) it returns an error message and does not
install or
configure the package depending on the severity of the
conflict
Those configuration questions that you come across on Debian systems
are run
through debconf:
http://en.wikipedia.org/wiki/Debconf_(software_package)
Debconf just passes the questions the install script has to whatever
front end you
use. I've only done a few KIDS installs, but it looks like one could
ask the install
questions through debconf and pass them onto KIDS.
I'm interested in working on this. I'm going to look up the proposal
and write up any comments.
~Jason
Butch
Nov 17, 2009, 8:06:43 AM11/17/09
to Hardhats
It should also be noted that similar measures can be accomplished with
rpm's, pkgadd, and ipkg (the latter two being Solaris and OpenSolaris
installers).
rpm's, pkgadd, and ipkg (the latter two being Solaris and OpenSolaris
installers).
Reply all
Reply to author
Forward
0 new messages