yellow team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

We have a few cards that might be related.  Brad and I talked about them
today.

The cards are these:

 * make root command to update system to newest/best configuration
 * Add banners to all created and modified configuration files in the
system.
 * interactive developer story

The first one is the most mysterious, and the crux of the conversation.
 Robert wants lpsetup to be able to not just set up a Launchpad
developer system but maintain it.  In the life of a developer's system,
after the developer has successfully created an environment for
launchpad development [1] and used it for awhile [2], a new version of
lpsetup may be available.  It may have new configurations and
workarounds.  Robert would like the developer to be able to run a
lpsetup command that will be able to smoothly handle the system upgrades
from the previous developer configuration to the current one.

The initlxc and inithost commands must be more than idempotent for this
to work.  They must be able to uninstall previous, discarded or improved
configurations.

I proposed that this could be accomplished by subdividing each
configuration element done by inithost and initlxc.  Each one could have
four callables.

 * Am I needed?  This may need to check what packages, or versions, are
on the system; or the version of the OS (Lucid, Precise, etc.); or
whether or not the host is an LXC container.
 * Am I installed?  This should be able to determine whether the
configuration has been performed, making whatever checks are necessary
(looking at file content, looking for installed packages, or simply
looking for some marker in the system).
 * Install.  This does the work, whatever it is.  It should always do it
in a way that can be cleanly reversed.
 * Uninstall.  Reverse an installation.

Each configuration change we ever make would need to stay around forever
in our files.  Configuration changes would be ordered.  We would use the
structure something like this.

 * For inithost, we would walk through all the inithost command's
configurations.  For each, code would ask, are you needed?  Are you
installed?  If you are not needed and installed, please uninstall; if
you are needed and not installed, please install; otherwise, no-op.
 * For initlxc, we would walk through the initlxc command's
configurations, and then call inithost in the container.  (The inithost
code can reliably discover it is running in a container and do
lxc-related jobs there, by the way.  I learned how from Serge.)

That's it.

The plan is related to the other two cards because it could fit in
nicely with them.

Banners added to created or modified files could be part of the markers
that the configuration uses to determine whether the change is
installed.  They don't have to be, but they could.  (They could even
include diffs as a comment, which could be used as an uninstall story if
we though that was a good idea.)

The interactive developer story could be supported by adding one or two
more items to each configuration: a description or title of the change
and a rationale.  Then the developer story could include a dry run
showing everything that would be installed and uninstalled, and why; and
could be the UI meat of an interactive yes/no step-by-step installation
story.

OK, have to run.  I look forward to talking about this with you all. Thanks!

Gary



[1] Creating the environment is roughly equivalent, with a bit of
variable glue left out, to "lpsetup inithost" or "lpsetup initlxc";
"lpsetup get"; and "lpsetup update."

[2] Using the enviroment on a daily basis would primarily consist of
"lpsetup update" with maybe a sprinkle of "lpsetup get" now and then.