Dave Miner wrote: >>> >> So are you suggesting that we let the user specify a manifest that might >> have been modified? Make it their responsibility to make sure >> they haven't changed anything critical? By allowing that we'd also give >> them flexibility to experiment more. I think that would be nice too. >> >> > > I'm suggesting that we not get overly restrictive in validating the > user's intentions, because the nature of the product here is to develop > things that we haven't necessarily thought of. That could mean merely > warning about things that appear inconsistent, or providing options to > ignore inconsistencies, or something like that. > > Dave > My personal thought about this is that allowing the user to provide different values in the manifest they use for restart is a must have. When I think about constructing an image, I would think that there are 2 category of things that can go wrong. The first category I considered to be system related, ie: disk is full, can't contact the IPS server...etc.. The second category are user modifications to the image to make it work, such as all the post processing stuff.
If the manifest for restart is not allowed to be changed, we only allow ppl to get around the first category of problem, which doesn't happen very often, I think. It's the second category that's more interesting, and that requires more experimentation from the user's point of view. Many of the modifications in category 2 might be values users specify in the manifest. So, I think that allowing a different manifest for restart is a must have. In terms of avoiding inconsistencies, one thought that I have is to store all the values used from the manifest when we construct from one step to the next, and enforce that a certain step and all the steps following it must be redone if values in the manifest from that step has been changed. --Karen
