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. -- Mailing list: https://launchpad.net/~yellow Post to : [email protected] Unsubscribe : https://launchpad.net/~yellow More help : https://help.launchpad.net/ListHelp
