Chris Lumens wrote: > Instead of talking about this right before every single release, let's > talk about it when there's still time to do something with it? For a > while now, we've been kicking around the idea of some sort of auto > updates mechanism - a way to tell anaconda to just go and get an > approved updates.img with important fixes from the release. > > Before I get started explaining this, I'd like everyone to keep in mind > that this should be completely separate from all the mirrors, ISO > images, etc. This is a whole other system in order to keep bureaucracy > and complexity to a minimum. > > I've always seen this as nothing more complicated than a directory > structure on a well-known website. anaconda assembles a URL, tries to > fetch the updates.img from there, and continues through to stage2 > regardless of if it works or not. Let me mention a couple issues I see > with supporting this, along with how I'd plan on handling them: > > (1) Updates can support both arch-independent Python files, as well as > shared libraries. We have occassionally made updates with libraries in > them. Additionally, we support several releases at a time. Our > directory structure should therefore support all these possibilities. > > I see anaconda trying to get a very specific updates.img first and if > that fails, try to get a progressively less specific image until it > either finds one or runs out of options. So first it would try to get: > > http://wherever/f10/i386/updates.img > > Failing that, it tries: > > http://wherever/f10/updates.img, http://wherever/updates.img > > Once that fails, anaconda keeps going without prompting. As long as we > use values we can determine from the .buildstamp or from the running > system, I think this plan works out fine. Since an updates.img would be tied to a specific release and architecture, let's tie it to the anaconda version number rather than the Fedora version number. loader could build the URL to look for. Maybe something like: http://wherever/anaconda-11.4.1.58/i386/updates.img Or: http://wherever/anaconda-11.4.1.58/updates.img It might also be worthwhile to merge an arch-specific updates.img with an arch-independent updates.img file, since we could possibly have an update that affects ppc only and everything else is arch-independent. You would only make the ppc one when you fixed that bug, the other bugs would get rolled in to the arch independent updates.img. The other thing that would be useful to build in to anaconda is a Python sanity check before continuing. If that fails, it tosses out the updates.img entirely before continuing. Pychecker or something similar, but something we could do at runtime. > (2) Getting mysterious files from a URL without asking never goes over > well. > > I'd prefer using updates=auto as the way to kick this off since then > we're not doing anything without asking. To make it easier, we could > put a new entry on the boot.iso menu that includes this option. Sounds reasonable. > (3) We need a process for deciding which bugs are important enough for > inclusion, then making sure they get some testing before being > published. > > I'm currently adding NeedsUpdatesImg to the whiteboard and putting the > bug in ON_QA when I commit a fix for it. Is this sufficient? I'd like > to keep the number of fixes relatively low or this gets very > complicated. Should the fixes be committed to the release's branch? > How do we give them enough testing? If the fix is not obvious, does > that mean it's too complicated for an update and should only be dealt > with in the next major release? We only ever hit a handful of bugs critical enough to warrant an updates.img and after a few weeks after a new release, things settle down. I think NeedsUpdatesImg in the whiteboard is reasonable. As for deciding which to include, we should probably discuss those on the list and figure out how many people are impacted. > (4) We'll need space to store these updates images that's guaranteed to > not go away. > > I don't really know what to say about this one. Infrastructure stuff > has always been mysterious to me. I think building on top of the current updates system and coming up with something that works with that is our best bet. Could we even ditch the idea of updates.img and just have loader pull down a new RPM of anaconda and use that? We could just use the updates system for that. I'm brainstorming here. > What am I missing here? It doesn't sound like very much work at all on > the anaconda side of things. As you said, I think the first thing we should set in stone (etch in to wiki) is the policy for what bugs make it in to an updates.img. Now I'm thinking more about having loader pull down a new anaconda RPM for the update and using that. -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat / Honolulu, HI _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
