68 lines
2.0 KiB
Plaintext
68 lines
2.0 KiB
Plaintext
|
Introduction to Lorax
|
||
|
|
=====================
|
||
|
|
|
||
|
|
I am the Lorax. I speak for the trees [and images].
|
||
|
|
|
||
|
|
Lorax is used to build the Anaconda Installer boot.iso, it consists of a
|
||
|
|
library, pylorax, a set of templates, and the lorax script. Its operation
|
||
|
|
is driven by a customized set of Mako templates that lists the packages
|
||
|
|
to be installed, steps to execute to remove unneeded files, and creation
|
||
|
|
of the iso for all of the supported architectures.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
Before Lorax
|
||
|
|
============
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
|
||
|
|
|