Lorax is a set of tools used to create bootable images.
Go to file
Brian C. Lane c9582a0468 Create a new YumBase object when repodata changes
The problem this solves is that yum really isn't designed to be part of\
a long running daemon. So when repodata changes upstream, even when
you force it to download the new metadata, it doesn't change in memory
so you end up with lorax-composer depsolving against old versions, and
anaconda depsolving against new versions (because it sets up its own
YumBase and cache) and then the kickstart is no longer valid.

To solve this I have
 - Added a 6h timeout to the metadata check (because yum's doesn't work
   in this situation).
 - Added a metadata check to the YumLock .lock property, but only when
   the timeout expires.
 - Added a new .lock_check property to YumLock that always checks the
   metadata and resets the timeout.

If it has changed it does its best to tear down the existing YumBase,
deleting as much as it can in hopes it doesn't leak memory. And then it
sets up a totally new YumBase with the new repodata.

Resolves: rhbz#1632962
2018-10-01 13:37:44 -07:00
docs Lock the root account, except on live-iso 2018-09-28 14:30:58 -07:00
etc Fix bash completion of compose info 2018-08-07 16:46:56 -07:00
rel-eng Automatic commit of package [lorax-composer] release [19.7.23-1]. 2018-09-19 08:30:34 -07:00
share Lock the root account, except on live-iso 2018-09-28 14:30:58 -07:00
src Create a new YumBase object when repodata changes 2018-10-01 13:37:44 -07:00
systemd Add PIDFile to the .service file. 2018-07-19 13:57:03 -04:00
tests Add a version glob test forprojects_depsolve_with_size 2018-10-01 11:09:20 -07:00
utils Don't redefine variables from outer scope 2018-06-11 16:54:57 -07:00
.coveragerc Measure coverage for parallel processes 2018-06-11 16:54:58 -07:00
.dockerignore Update how we pass the source to docker so it includes docs/ dir 2018-06-11 16:54:58 -07:00
.gitignore Add a pylorax.api.version number 2018-08-21 12:10:01 -07:00
.travis.yml Properly report coverage 2018-06-11 16:54:58 -07:00
ANNOUNCE Added draft on initial announce email as I keep adding to it. 2008-10-06 09:51:01 -10:00
AUTHORS add wwoods to AUTHORS 2011-10-26 12:36:06 -04:00
COPYING Initial project description files imported. 2008-09-11 14:16:39 -10:00
Dockerfile.test Install anaconda-tui in the test Docker image 2018-06-11 16:54:58 -07:00
epel.repo Enable testing in Travis CI using Docker container 2018-06-11 16:54:58 -07:00
lorax-composer.spec Automatic commit of package [lorax-composer] release [19.7.23-1]. 2018-09-19 08:30:34 -07:00
Makefile Add a pylorax.api.version number 2018-08-21 12:10:01 -07:00
POLICY Update TODO and POLICY to reflect the current state of things 2012-01-06 14:41:21 -05:00
README Initial project description files imported. 2008-09-11 14:16:39 -10:00
README.livemedia-creator Document kickstart restrictions on %include (#1418500) 2017-08-11 15:11:30 -07:00
README.product Update docs for product.img (#1272361) 2016-02-19 16:41:58 -08:00
setup.py Add support for systemd socket activation 2018-06-11 16:54:59 -07:00
TODO Update TODO and POLICY to reflect the current state of things 2012-01-06 14:41:21 -05:00

I am the Lorax.  I speak for the trees [and images].

Tree building tools such as pungi and revisor rely on 'buildinstall' in
anaconda/scripts/ to produce the boot images and other such control files
in the final tree.  The existing buildinstall scripts written in a mix of
bash and Python are unmaintainable.  Lorax is an attempt to replace them
with something more flexible.


EXISTING WORKFLOW:

pungi and other tools call scripts/buildinstall, which in turn call other
scripts to do the image building and data generation.  Here's how it
currently looks:

   -> buildinstall
       * process command line options
       * write temporary yum.conf to point to correct repo
       * find anaconda release RPM
       * unpack RPM, pull in those versions of upd-instroot, mk-images,
         maketreeinfo.py, makestamp.py, and buildinstall

       -> call upd-instroot

       -> call maketreeinfo.py

       -> call mk-images (which figures out which mk-images.ARCH to call)

       -> call makestamp.py

       * clean up


PROBLEMS:

The existing workflow presents some problems with maintaining the scripts.
First, almost all knowledge of what goes in to the stage 1 and stage 2
images lives in upd-instroot.  The mk-images* scripts copy things from the
root created by upd-instroot in order to build the stage 1 image, though
it's not completely clear from reading the scripts.


NEW IDEAS:

Create a new central driver with all information living in Python modules.
Configuration files will provide the knowledge previously contained in the
upd-instroot and mk-images* scripts.


-- 
David Cantrell <dcantrell@redhat.com>