diff --git a/.gitignore b/.gitignore
index acde37a4..9b928085 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 *.pyc
 src/pylorax/version.py*
+_build/
diff --git a/Makefile b/Makefile
index 7106c6b6..d9206693 100644
--- a/Makefile
+++ b/Makefile
@@ -31,6 +31,9 @@ clean:
 tag:
 	git tag -f $(TAG)
 
+docs:
+	$(MAKE) -C docs apidoc
+
 archive:
 	@git archive --format=tar --prefix=$(PKGNAME)-$(VERSION)/ $(TAG) > $(PKGNAME)-$(VERSION).tar
 	@gzip $(PKGNAME)-$(VERSION).tar
diff --git a/README.livemedia-creator b/README.livemedia-creator
deleted file mode 100644
index 99dbb89f..00000000
--- a/README.livemedia-creator
+++ /dev/null
@@ -1,378 +0,0 @@
-
-INTRO
------
-livemedia-creator uses Anaconda, kickstart and Lorax to create bootable media
-that use the same install path as a normal system install. It can be used to
-make live isos, bootable (partitioned) disk images and filesystem images for
-use with virtualization.
-
-The general idea is to use virt-install to install into a disk image and then
-use the disk image to create the bootable media.
-
-livemedia-creator --help will describe all of the options available. At the
-minimum you need:
-
---make-iso to create a final bootable .iso
---iso to specify the Anaconda install media to use with virt-install
---ks is the kickstart to use to install the system
-
-To use livemedia-creator with virt-install you will need to install the
-following packages, as well as have libvirtd setup correctly.
-  virt-install
-  libvirt-python
-
-If you are going to be using Anaconda directly, with --no-virt mode, make sure
-you have the anaconda package installed.
-
-
-QUICKSTART
-----------
-sudo livemedia-creator --make-iso \
---iso=/extra/iso/Fedora-18-x86_64-netinst.iso --ks=./docs/fedora-livemedia.ks
-
-If you are using the lorax git repo you can run it like so:
-
-sudo PATH=./src/sbin/:$PATH PYTHONPATH=./src/ ./src/sbin/livemedia-creator \
---make-iso --iso=/extra/iso/Fedora-18-x86_64-netinst.iso \
---ks=./docs/fedora-livemedia.ks --lorax-templates=./share/
-
-If you want to watch the install you can pass '--vnc vnc' and use a vnc
-client to connect to localhost:0
-
-This is usually a good idea when testing changes to the kickstart. It tries
-to monitor the logs for fatal errors, but may not catch everything.
-
-
-HOW IT WORKS
-------------
-There are 2 stages, the install stage which produces a disk or filesystem
-image as its output, and the boot media creation which uses the image as
-its input. Normally you would have it run both stages, but it is possible
-to have it stop after the install stage, using --image-only, or to have it
-skip the install stage and use a previously created disk image by passing
---disk-image or --fs-image
-
-When creating an iso virt-install boots using the passed Anaconda installer iso
-and installs the system based on the kickstart. The %post section of the
-kickstart is used to customize the installed system in the same way that
-current spin-kickstarts do.
-
-livemedia-creator monitors the install process for problems by watching the
-install logs. They are written to the current directory or to the base
-directory specified by the --logfile command. You can also monitor the install
-by passing --vnc vnc and using a vnc client. This is recommended when first
-modifying a kickstart, since there are still places where Anaconda may get
-stuck without the log monitor catching it.
-
-The output from this process is a partitioned disk image. kpartx can be used
-to mount and examine it when there is a problem with the install. It can also
-be booted using kvm.
-
-When creating an iso the disk image's / partition is copied into a formatted
-disk image which is then used as the input to lorax for creation of the final
-media.
-
-The final image is created by lorax, using the templates in /usr/share/lorax/
-or the directory specified by --lorax-templates
-
-Currently the standard lorax templates are used to make a bootable iso, but
-it should be possible to modify them to output other results. They are
-written using the Mako template system which is very flexible.
-
-
-KICKSTARTS
-----------
-The docs/ directory includes two example kickstarts, one to create a live desktop
-iso using GNOME, and the other to create a minimal disk image. When creating your
-own kickstarts you should start with the minimal example, it includes several
-needed packages that are not always included by dependencies.
-
-Or you can use existing spin kickstarts to create live media with a few
-changes. Here are the steps I used to convert the Fedora XFCE spin.
-
-1. Flatten the xfce kickstart using ksflatten
-2. Add zerombr so you don't get the disk init dialog
-3. Add clearpart --all
-4. Add swap partition
-5. bootloader target
-6. Add shutdown to the kickstart
-7. Add network --bootproto=dhcp --activate to activate the network
-   This works for F16 builds but for F15 and before you need to pass
-   something on the cmdline that activate the network, like sshd.
-
-livemedia-creator --kernel-args="sshd"
-
-8. Add a root password
-
-rootpw rootme
-network --bootproto=dhcp --activate
-zerombr
-clearpart --all
-bootloader --location=mbr
-part swap --size=512
-shutdown
-
-9. In the livesys script section of the %post remove the root password. This
-   really depends on how the spin wants to work. You could add the live user
-   that you create to the %wheel group so that sudo works if you wanted to.
-
-passwd -d root > /dev/null
-
-10. Remove /etc/fstab in %post, dracut handles mounting the rootfs
-
-cat /dev/null > /dev/fstab
-
-    Do this only for live iso's, the filesystem will be mounted read only if
-    there is no /etc/fstab
-
-11. Don't delete initramfs files from /boot in %post
-12. Have dracut-config-generic, grub-efi, memtest86+ and syslinux in the package
-    list.
-13. Omit dracut-config-rescue from the package list "-dracut-config-rescue"
-
-One drawback to using virt-install is that it pulls the packages from
-the repo each time you run it. To speed things up you either need a local
-mirror of the packages, or you can use a caching proxy. When using a proxy
-you pass it to livemedia-creator like so:
-
---proxy=http://proxy.yourdomain.com:3128
-
-You also need to use a specific mirror instead of mirrormanager so that the
-packages will get cached, so your kickstart url would look like:
-
-url --url="http://dl.fedoraproject.org/pub/fedora/linux/development/17/x86_64/os/"
-
-You can also add an update repo, but don't name it updates. Add --proxy to
-it as well.
-
-
-ANACONDA IMAGE INSTALL
-----------------------
-You can create images without using virt-install by passing --no-virt on the
-cmdline. This will use Anaconda's directory install feature to handle the install.
-There are a couple of things to keep in mind when doing this:
-
-1. It will be most reliable when building images for the same release that the
-   host is running. Because Anaconda has expectations about the system it is
-   running under you may encounter strange bugs if you try to build newer or
-   older releases.
-
-2. Make sure selinux is set to permissive or disabled. It won't install
-   correctly with selinux set to enforcing yet.
-
-3. It may totally trash your host. So far I haven't had this happen, but the
-   possibility exists that a bug in Anaconda could result in it operating on
-   real devices. I recommend running it in a virt or on a system that you can
-   afford to lose all data from.
-
-The logs from anaconda will be placed in an ./anaconda/ directory in either
-the current directory or in the directory used for --logfile
-
-Example cmdline:
-
-sudo livemedia-creator --make-iso --no-virt --ks=./fedora-livemedia.ks
-
-
-AMI IMAGES
-----------
-Amazon EC2 images can be created by using the --make-ami switch and an appropriate
-kickstart file. All of the work to customize the image is handled by the kickstart.
-The example currently included was modified from the cloud-kickstarts version so
-that it would work with livemedia-creator.
-
-Example cmdline:
-sudo livemedia-creator --make-ami --iso=/path/to/boot.iso --ks=./docs/fedora-livemedia-ec2.ks
-
-This will produce an ami-root.img file in the working directory.
-
-At this time I have not tested the image with EC2. Feedback would be welcome.
-
-
-APPLIANCE CREATION
-------------------
-livemedia-creator can now replace appliance-tools by using the --make-appliance
-switch. This will create the partitioned disk image and an XML file that can be
-used with virt-image to setup a virtual system.
-
-The XML is generated using the Mako template from
-/usr/share/lorax/appliance/libvirt.xml You can use a different template by
-passing --app-template <template path>
-
-Documentation on the Mako template system can be found here:
-http://docs.makotemplates.org/en/latest/index.html
-
-The name of the final output XML is appliance.xml, this can be changed with
---app-file <file path>
-
-The following variables are passed to the template:
-disks           A list of disk_info about each disk.
-                Each entry has the following attributes:
-    name           base name of the disk image file
-    format         "raw"
-    checksum_type  "sha256"
-    checksum       sha256 checksum of the disk image
-name            Name of appliance, from --app-name argument
-arch            Architecture
-memory          Memory in KB (from --ram)
-vcpus           from --vcpus
-networks        list of networks from the kickstart or []
-title           from --title
-project         from --project
-releasever      from --releasever
-
-The created image can be imported into libvirt using:
-
-virt-image appliance.xml
-
-You can also create qcow2 appliance images using --qcow2, for example:
-sudo livemedia-creator --make-appliance --iso=/path/to/boot.iso --ks=./docs/fedora-minimal.ks \
---qcow2 --app-file=minimal-test.xml --image-name=minimal-test.img
-
-
-FILESYSTEM IMAGE CREATION
--------------------------
-livemedia-creator can be used to create un-partitined filesystem images using the
---make-fsimage option. As of version 21.8 this works with both virt-install and no-virt. Previously
-it was only available with --no-virt.
-
-Kickstarts should have a single / partition with no extra mountpoints.
-
-livemedia-creator --make-fsimage --iso=/path/to/boot.iso --ks=./docs/fedora-minimal.ks
-
-You can name the output image with --image-name and set a label on the filesystem with --fs-label
-
-
-TAR FILE CREATION
------------------
-The --make-tar command can be used to create a tar of the root filesystem. By
-default it is compressed using xz, but this can be changed using the
---compression and --compress-arg options. This option works with both virt and
---no-virt install methods.
-
-As with --make-fsimage the kickstart should be limited to a single / partition.
-
-eg.
-
-livemedia-creator --make-tar --iso=/path/to/boot.iso --ks=./docs/fedora-minimal.ks \
---image-name=fedora-root.tar.xz
-
-LIVE IMAGE FOR PXE BOOT
------------------------
-
-The --make-pxe-live command will produce squashfs image containing live root
-filesystem that can be used for pxe boot. Directory with results will contain
-the live image, kernel image, initrd image and template of pxe configuration
-for the images.
-
-ATOMIC LIVE IMAGE FOR PXE BOOT
-------------------------------
-
-The --make-ostree-live command will produce the same result as --make-pxe-live
-for installations of Atomic Host.  Example kickstart for such an installation
-using Atomic installer iso with local repo included in the image can be found
-in docs/rhel-atomic-pxe-live.ks.
-
-USING MOCK TO CREATE IMAGES
----------------------------
-
-As of lorax version 22.2 you can use livemedia-creator and anaconda version
-22.15 inside of a mock chroot with --make-iso and --make-fsimage. Note that
-this requires bind mounting the host's /dev/ directory into the mock, which
-could be dangerous since it includes the host's drives. You can work around
-this by /dev/loopX nodes before running livemedia-creator. This example does
-not do that.
-
-On the host system:
-1. yum install -y mock
-
-2. Add a user to the mock group to use for running mock. eg. builder
-
-3. Edit the /etc/mock/site-defaults.cfg file to change:
-
-   config_opts['internal_dev_setup'] = False
-
-   The loop devices are needed for the installation, so it needs to mount the
-   host's /dev/ inside the mock.
-
-   This is fairly dangerous. I would recommend using a dedicated build host and
-   making sure you have backups just in case something goes wrong and it
-   modifies the host system.  You can avoid this if you setup the /dev/loopX
-   device nodes yourself.
-
-4. Create a new /etc/mock/ config file based on the rawhide one, or modify the
-   existing one so that the following options are setup:
-
-   config_opts['chroot_setup_cmd'] = 'install @buildsys-build anaconda-tui lorax'
-
-   # NOTE that this actually needs to be set in site-defaults.cfg
-   config_opts['internal_dev_setup'] = False
-
-   # Mount the relevant host paths inside the mock /dev/
-   config_opts['plugin_conf']['bind_mount_enable'] = True
-   config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/dev','/dev/'))
-   config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/dev/pts','/dev/pts/'))
-   config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/dev/shm','/dev/shm/'))
-
-   # build results go into /home/builder/results/
-   config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/home/builder/results','/results/'))
-
-The following steps are run as the builder user who is a member of the mock
-group.
-
-5. Make a directory for results matching the bind mount above
-   mkdir ~/results/
-
-6. Copy the example kickstarts
-   cp /usr/share/docs/lorax/*ks .
-
-7. Make sure tar and dracut-network are in the %packages section and that the
-   url points to the correct repo
-
-8. Init the mock
-   mock -r fedora-rawhide-x86_64 --init
-
-9. Copy the kickstart inside the mock
-   mock -r fedora-rawhide-x86_64 --copyin ./fedora-minimal.ks /root/
-
-10. Make a minimal iso:
-    mock -r fedora-rawhide-x86_64 --chroot -- livemedia-creator --no-virt \
-    --resultdir=/results/try-1 --logfile=/results/logs/try-1/try-1.log \
-    --make-iso --ks /root/fedora-minimal.ks
-
-Results will be in ./results/try-1 and logs under /results/logs/try-1/
-including anaconda logs and livemedia-creator logs. The new iso will be
-located at ~/results/try-1/images/boot.iso, and the ~/results/try-1/
-directory tree will also contain the vmlinuz, initrd, etc.
-
-
-DEBUGGING PROBLEMS
-------------------
-Cleaning up an aborted (ctrl-c) virt-install run (as root):
-virsh list to show the name of the virt
-virsh destroy <name>
-virsh undefine <name>
-umount /tmp/tmpXXXX
-rm -rf /tmp/tmpXXXX
-rm /tmp/diskXXXXX
-
-The logs from the virt-install run are stored in virt-install.log,
-logs from livemedia-creator are in livemedia.log and program.log
-
-You can add --image-only to skip the .iso creation and examine the resulting
-disk image. Or you can pass --keep-image to keep it around after lorax is
-run.
-
-Cleaning up aborted --no-virt installs can sometimes be accomplished by running
-the anaconda-cleanup script. As of f18 anaconda is multi-threaded and it can
-sometimes become stuck and refuse to exit. When this happens you can usually
-clean up by first killing the anaconda process then running anaconda-cleanup.
-
-
-HACKING
--------
-Development on this will take place as part of the lorax project, and on the
-anaconda-devel-list mailing list.
-
-Feedback, enhancements and bugs are welcome.
-You can use http://bugzilla.redhat.com to report bugs.
-
diff --git a/docs/Makefile b/docs/Makefile
new file mode 100644
index 00000000..9cf59fce
--- /dev/null
+++ b/docs/Makefile
@@ -0,0 +1,184 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+SPHINXAPIDOC  = sphinx-apidoc
+PAPER         =
+BUILDDIR      = _build
+SOURCEDIR     = ../src/
+MODULE_NAMES  = pylorax.rst modules.rst
+
+# User-friendly check for sphinx-build
+ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
+$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
+endif
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  dirhtml    to make HTML files named index.html in directories"
+	@echo "  singlehtml to make a single large HTML file"
+	@echo "  pickle     to make pickle files"
+	@echo "  json       to make JSON files"
+	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  qthelp     to make HTML files and a qthelp project"
+	@echo "  devhelp    to make HTML files and a Devhelp project"
+	@echo "  epub       to make an epub"
+	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
+	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
+	@echo "  text       to make text files"
+	@echo "  man        to make manual pages"
+	@echo "  texinfo    to make Texinfo files"
+	@echo "  info       to make Texinfo files and run them through makeinfo"
+	@echo "  gettext    to make PO message catalogs"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  xml        to make Docutils-native XML files"
+	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"
+	@echo "  linkcheck  to check all external links for integrity"
+	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+	rm -rf $(BUILDDIR)/*
+
+apidoc:
+	-rm $(addprefix ./, $(MODULE_NAMES))
+	$(SPHINXAPIDOC) -o . $(SOURCEDIR)
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+singlehtml:
+	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/src.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/src.qhc"
+
+devhelp:
+	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+	@echo
+	@echo "Build finished."
+	@echo "To view the help file:"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/src"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/src"
+	@echo "# devhelp"
+
+epub:
+	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+
+latexpdf:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through pdflatex..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+latexpdfja:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through platex and dvipdfmx..."
+	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+text:
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+man:
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+texinfo:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo
+	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+	@echo "Run \`make' in that directory to run these through makeinfo" \
+	      "(use \`make info' here to do that automatically)."
+
+info:
+	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+	@echo "Running Texinfo files through makeinfo..."
+	make -C $(BUILDDIR)/texinfo info
+	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+gettext:
+	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+	@echo
+	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."
+
+xml:
+	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
+	@echo
+	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."
+
+pseudoxml:
+	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
+	@echo
+	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
diff --git a/docs/conf.py b/docs/conf.py
new file mode 100644
index 00000000..4165a84f
--- /dev/null
+++ b/docs/conf.py
@@ -0,0 +1,382 @@
+# -*- coding: utf-8 -*-
+#
+# src documentation build configuration file, created by
+# sphinx-quickstart on Wed Apr  8 13:46:00 2015.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.insert(0, os.path.abspath('../src/'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = [
+    'sphinx.ext.autodoc',
+    'sphinx.ext.viewcode',
+    'sphinx.ext.intersphinx',
+    'sphinx.ext.todo',
+    'sphinx.ext.coverage'
+]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'Lorax'
+copyright = u'2015, Red Hat, Inc.'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+def read_version():
+    """ Read version from ../lorax.spec"""
+    import re
+    version_re = re.compile(r"Version:\s+(.*)")
+    with open("../lorax.spec", "rt") as f:
+        for line in f:
+            m = version_re.match(line)
+            if m:
+                return m.group(1)
+
+#
+# The short X.Y version.
+version = read_version()
+# The full version, including alpha/beta/rc tags.
+release = version
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'default'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'Loraxdoc'
+
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+  ('index', 'Lorax.tex', u'Lorax Documentation',
+   u'Anaconda Team', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    ('index', 'Lorax', u'Lorax Documentation',
+     [u'Anaconda Team'], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+  ('index', 'Lorax', u'Lorax Documentation',
+   u'Anaconda Team', 'Lorax', 'One line description of project.',
+   'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
+
+
+# -- Options for Epub output ----------------------------------------------
+
+# Bibliographic Dublin Core info.
+epub_title = u'Lorax'
+epub_author = u'Anaconda Team'
+epub_publisher = u'Anaconda Team'
+epub_copyright = u'2015, Red Hat, Inc.'
+
+# The basename for the epub file. It defaults to the project name.
+#epub_basename = u'src'
+
+# The HTML theme for the epub output. Since the default themes are not optimized
+# for small screen space, using the same theme for HTML and epub output is
+# usually not wise. This defaults to 'epub', a theme designed to save visual
+# space.
+#epub_theme = 'epub'
+
+# The language of the text. It defaults to the language option
+# or en if the language is not set.
+#epub_language = ''
+
+# The scheme of the identifier. Typical schemes are ISBN or URL.
+#epub_scheme = ''
+
+# The unique identifier of the text. This can be a ISBN number
+# or the project homepage.
+#epub_identifier = ''
+
+# A unique identification for the text.
+#epub_uid = ''
+
+# A tuple containing the cover image and cover page html template filenames.
+#epub_cover = ()
+
+# A sequence of (type, uri, title) tuples for the guide element of content.opf.
+#epub_guide = ()
+
+# HTML files that should be inserted before the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_pre_files = []
+
+# HTML files shat should be inserted after the pages created by sphinx.
+# The format is a list of tuples containing the path and title.
+#epub_post_files = []
+
+# A list of files that should not be packed into the epub file.
+epub_exclude_files = ['search.html']
+
+# The depth of the table of contents in toc.ncx.
+#epub_tocdepth = 3
+
+# Allow duplicate toc entries.
+#epub_tocdup = True
+
+# Choose between 'default' and 'includehidden'.
+#epub_tocscope = 'default'
+
+# Fix unsupported image types using the PIL.
+#epub_fix_images = False
+
+# Scale large images.
+#epub_max_image_width = 0
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#epub_show_urls = 'inline'
+
+# If false, no index is generated.
+#epub_use_index = True
+
+# Example configuration for intersphinx: refer to the Python standard library.
+intersphinx_mapping = {'https://docs.python.org/2': None}
+
+# This was taken directly from here:
+# http://read-the-docs.readthedocs.org/en/latest/faq.html#i-get-import-errors-on-libraries-that-depend-on-c-modules
+# I only added the __getitem__ method.
+# NOTE: this can be removed whenever we move to sphinx-1.3, at which point we'll
+#       be able to use autodoc_mock_imports (value is a list of modules to be
+#       mocked).
+class Mock(object):
+
+    __all__ = []
+
+    def __init__(self, *args, **kwargs):
+        pass
+
+    def __call__(self, *args, **kwargs):
+        return Mock()
+
+    @classmethod
+    def __getattr__(cls, name):
+        if name in ('__file__', '__path__'):
+            return '/dev/null'
+        elif name[0] == name[0].upper():
+            mockType = type(name, (), {})
+            mockType.__module__ = __name__
+            return mockType
+        else:
+            return Mock()
+
+    @classmethod
+    def __getitem__(cls, key):
+        return cls.__getattr__(key)
+
+MOCK_MODULES = []
+for mod_name in MOCK_MODULES:
+    sys.modules[mod_name] = Mock()
diff --git a/docs/fedora-docker.ks b/docs/fedora-docker.ks
new file mode 100644
index 00000000..009ae968
--- /dev/null
+++ b/docs/fedora-docker.ks
@@ -0,0 +1,37 @@
+# Minimal Disk Image
+
+# Use network installation
+url --url="http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/"
+
+# Root password
+rootpw --plaintext replace-this-pw
+# Network information
+network  --bootproto=dhcp --activate
+# System authorization information
+auth --useshadow --enablemd5
+# System keyboard
+keyboard --xlayouts=us --vckeymap=us
+# System language
+lang en_US.UTF-8
+# SELinux configuration
+selinux --enforcing
+# Installation logging level
+logging --level=info
+# Shutdown after installation
+shutdown
+# System timezone
+timezone  US/Eastern
+# System bootloader configuration
+bootloader --disabled
+# Clear the Master Boot Record
+zerombr
+# Partition clearing information
+clearpart --all
+# Disk partitioning information
+part / --fstype="ext4" --size=3000
+
+
+%packages --nocore --instLangs en
+httpd
+-kernel
+%end
diff --git a/docs/fedora-openstack.ks b/docs/fedora-openstack.ks
new file mode 100644
index 00000000..678c487f
--- /dev/null
+++ b/docs/fedora-openstack.ks
@@ -0,0 +1,53 @@
+# Minimal Disk Image
+#
+# Firewall configuration
+firewall --enabled
+# Use network installation
+url --url="http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/"
+
+# Root password
+rootpw --plaintext replace-this-pw
+# Network information
+network  --bootproto=dhcp --activate
+# System authorization information
+auth --useshadow --enablemd5
+# System keyboard
+keyboard --xlayouts=us --vckeymap=us
+# System language
+lang en_US.UTF-8
+# SELinux configuration
+selinux --enforcing
+# Installation logging level
+logging --level=info
+# Shutdown after installation
+shutdown
+# System timezone
+timezone  US/Eastern
+# System bootloader configuration
+bootloader --location=mbr
+# Clear the Master Boot Record
+zerombr
+# Partition clearing information
+clearpart --all
+# Disk partitioning information
+part / --fstype="ext4" --size=3000
+
+%packages
+@core
+kernel
+memtest86+
+grub2-efi
+grub2
+shim
+syslinux
+-dracut-config-rescue
+
+# dracut needs these included
+dracut-network
+tar
+
+# Openstack support
+cloud-utils-growpart
+cloud-init
+
+%end
diff --git a/docs/index.rst b/docs/index.rst
new file mode 100644
index 00000000..66002511
--- /dev/null
+++ b/docs/index.rst
@@ -0,0 +1,27 @@
+.. Lorax documentation master file, created by
+   sphinx-quickstart on Wed Apr  8 13:46:00 2015.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Welcome to Lorax's documentation!
+=================================
+
+Contents:
+
+.. toctree::
+   :maxdepth: 1
+
+   intro
+   lorax
+   livemedia-creator
+   product-images
+   pylorax
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
diff --git a/docs/intro.rst b/docs/intro.rst
new file mode 100644
index 00000000..01857ee9
--- /dev/null
+++ b/docs/intro.rst
@@ -0,0 +1,67 @@
+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.
+
+
+
diff --git a/docs/livemedia-creator.rst b/docs/livemedia-creator.rst
new file mode 100644
index 00000000..3b8c3a2b
--- /dev/null
+++ b/docs/livemedia-creator.rst
@@ -0,0 +1,500 @@
+livemedia-creator
+=================
+
+:Authors:
+    Brian C. Lane <bcl@redhat.com>
+
+livemedia-creator uses `Anaconda <https://github.com/rhinstaller/anaconda>`_,
+`kickstart <https://github.com/rhinstaller/pykickstart>`_ and `Lorax
+<https://github.com/rhinstaller/lorax>`_ to create bootable media that use the
+same install path as a normal system installation. It can be used to make live
+isos, bootable (partitioned) disk images, tarfiles, and filesystem images for
+use with virtualization and container solutions like libvirt, docker, and
+OpenStack.
+
+The general idea is to use virt-install with kickstart and an Anaconda boot.iso
+to install into a disk image and then use the disk image to create the bootable
+media.
+
+livemedia-creator --help will describe all of the options available. At the
+minimum you need:
+
+``--make-iso`` to create a final bootable .iso or one of the other ``--make-*`` options.
+
+``--iso`` to specify the Anaconda install media to use with virt-install
+
+``--ks`` to select the kickstart file describing what to install.
+
+To use livemedia-creator with virt-install you will need to install the
+following packages, as well as have libvirtd setup correctly.
+
+* ``virt-install``
+* ``libvirt-python``
+
+If you are going to be using Anaconda directly, with ``--no-virt`` mode, make sure
+you have the anaconda package installed. You can use the anaconda-tui package
+to save a bit of space on the build system.
+
+Conventions used in this document:
+
+``lmc`` is an abbreviation for livemedia-creator.
+
+``builder`` is the system where livemedia-creator is being run
+
+``image`` is the disk image being created by running livemedia-creator
+
+
+Quickstart
+----------
+
+Run this to create a bootable live iso::
+
+    sudo livemedia-creator --make-iso \
+    --iso=/extra/iso/boot.iso --ks=./docs/fedora-livemedia.ks
+
+You can run it directly from the lorax git repo like this::
+
+    sudo PATH=./src/sbin/:$PATH PYTHONPATH=./src/ ./src/sbin/livemedia-creator \
+    --make-iso --iso=/extra/iso/boot.iso \
+    --ks=./docs/fedora-livemedia.ks --lorax-templates=./share/
+
+If you want to watch the install you can pass ``--vnc vnc`` and use a vnc client
+to connect to localhost:0
+
+This is usually a good idea when testing changes to the kickstart. lmc tries
+to monitor the logs for fatal errors, but may not catch everything.
+
+
+How ISO creation works
+----------------------
+
+There are 2 stages, the install stage which produces a disk or filesystem image
+as its output, and the boot media creation which uses the image as its input.
+Normally you would run both stages, but it is possible to stop after the
+install stage, by using ``--image-only``, or to skip the install stage and use
+a previously created disk image by passing ``--disk-image`` or ``--fs-image``
+
+When creating an iso virt-install boots using the passed Anaconda installer iso
+and installs the system based on the kickstart. The ``%post`` section of the
+kickstart is used to customize the installed system in the same way that
+current spin-kickstarts do.
+
+livemedia-creator monitors the install process for problems by watching the
+install logs. They are written to the current directory or to the base
+directory specified by the --logfile command. You can also monitor the install
+by passing ``--vnc vnc`` and using a vnc client. This is recommended when first
+modifying a kickstart, since there are still places where Anaconda may get
+stuck without the log monitor catching it.
+
+The output from this process is a partitioned disk image. kpartx can be used
+to mount and examine it when there is a problem with the install. It can also
+be booted using kvm.
+
+When creating an iso the disk image's / partition is copied into a formatted
+disk image which is then used as the input to lorax for creation of the final
+media.
+
+The final image is created by lorax, using the templates in /usr/share/lorax/
+or the directory specified by ``--lorax-templates``
+
+Currently the standard lorax templates are used to make a bootable iso, but
+it should be possible to modify them to output other results. They are
+written using the Mako template system which is very flexible.
+
+
+Kickstarts
+----------
+
+The docs/ directory includes several example kickstarts, one to create a live
+desktop iso using GNOME, and another to create a minimal disk image. When
+creating your own kickstarts you should start with the minimal example, it
+includes several needed packages that are not always included by dependencies.
+
+Or you can use existing spin kickstarts to create live media with a few
+changes. Here are the steps I used to convert the Fedora XFCE spin.
+
+1. Flatten the xfce kickstart using ksflatten
+2. Add zerombr so you don't get the disk init dialog
+3. Add clearpart --all
+4. Add swap partition
+5. bootloader target
+6. Add shutdown to the kickstart
+7. Add network --bootproto=dhcp --activate to activate the network
+   This works for F16 builds but for F15 and before you need to pass
+   something on the cmdline that activate the network, like sshd:
+
+    ``livemedia-creator --kernel-args="sshd"``
+
+8. Add a root password::
+
+    rootpw rootme
+    network --bootproto=dhcp --activate
+    zerombr
+    clearpart --all
+    bootloader --location=mbr
+    part swap --size=512
+    shutdown
+
+9. In the livesys script section of the %post remove the root password. This
+   really depends on how the spin wants to work. You could add the live user
+   that you create to the %wheel group so that sudo works if you wanted to.
+
+    ``passwd -d root > /dev/null``
+
+10. Remove /etc/fstab in %post, dracut handles mounting the rootfs
+
+    ``cat /dev/null > /dev/fstab``
+
+    Do this only for live iso's, the filesystem will be mounted read only if
+    there is no /etc/fstab
+
+11. Don't delete initramfs files from /boot in %post
+12. Have dracut-config-generic, grub-efi, memtest86+ and syslinux in the package
+    list.
+13. Omit dracut-config-rescue from the %package list: ``-dracut-config-rescue``
+
+One drawback to using virt-install is that it pulls the packages from
+the repo each time you run it. To speed things up you either need a local
+mirror of the packages, or you can use a caching proxy. When using a proxy
+you pass it to livemedia-creator like this:
+
+    ``--proxy=http://proxy.yourdomain.com:3128``
+
+You also need to use a specific mirror instead of mirrormanager so that the
+packages will get cached, so your kickstart url would look like:
+
+    ``url --url="http://dl.fedoraproject.org/pub/fedora/linux/development/17/x86_64/os/"``
+
+You can also add an update repo, but don't name it updates. Add --proxy to
+it as well.
+
+
+Anaconda image install (no-virt)
+--------------------------------
+
+You can create images without using virt-install by passing ``--no-virt`` on the
+cmdline. This will use Anaconda's directory install feature to handle the install.
+There are a couple of things to keep in mind when doing this:
+
+1. It will be most reliable when building images for the same release that the
+   host is running. Because Anaconda has expectations about the system it is
+   running under you may encounter strange bugs if you try to build newer or
+   older releases.
+
+2. Make sure selinux is set to permissive or disabled. It won't install
+   correctly with selinux set to enforcing yet.
+
+3. It may totally trash your host. So far I haven't had this happen, but the
+   possibility exists that a bug in Anaconda could result in it operating on
+   real devices. I recommend running it in a virt or on a system that you can
+   afford to lose all data from.
+
+The logs from anaconda will be placed in an ./anaconda/ directory in either
+the current directory or in the directory used for --logfile
+
+Example cmdline:
+
+``sudo livemedia-creator --make-iso --no-virt --ks=./fedora-livemedia.ks``
+
+
+AMI Images
+----------
+
+Amazon EC2 images can be created by using the --make-ami switch and an appropriate
+kickstart file. All of the work to customize the image is handled by the kickstart.
+The example currently included was modified from the cloud-kickstarts version so
+that it would work with livemedia-creator.
+
+Example cmdline:
+
+``sudo livemedia-creator --make-ami --iso=/path/to/boot.iso --ks=./docs/fedora-livemedia-ec2.ks``
+
+This will produce an ami-root.img file in the working directory.
+
+At this time I have not tested the image with EC2. Feedback would be welcome.
+
+
+Appliance Creation
+------------------
+
+livemedia-creator can now replace appliance-tools by using the --make-appliance
+switch. This will create the partitioned disk image and an XML file that can be
+used with virt-image to setup a virtual system.
+
+The XML is generated using the Mako template from
+/usr/share/lorax/appliance/libvirt.xml You can use a different template by
+passing ``--app-template <template path>``
+
+Documentation on the Mako template system can be found at the `Mako site
+<http://docs.makotemplates.org/en/latest/index.html>`_
+
+The name of the final output XML is appliance.xml, this can be changed with
+``--app-file <file path>``
+
+The following variables are passed to the template:
+
+    ``disks``
+       A list of disk_info about each disk.
+       Each entry has the following attributes:
+
+        ``name``
+        base name of the disk image file
+
+        ``format``
+        "raw"
+
+        ``checksum_type``
+        "sha256"
+
+        ``checksum``
+        sha256 checksum of the disk image
+
+    ``name``
+    Name of appliance, from --app-name argument
+
+    ``arch``
+    Architecture
+
+    ``memory``
+    Memory in KB (from ``--ram``)
+
+    ``vcpus``
+    from ``--vcpus``
+
+    ``networks``
+    list of networks from the kickstart or []
+
+    ``title``
+    from ``--title``
+
+    ``project``
+    from ``--project``
+
+    ``releasever``
+    from ``--releasever``
+
+The created image can be imported into libvirt using:
+
+    ``virt-image appliance.xml``
+
+You can also create qcow2 appliance images using ``--qcow2``, for example::
+
+    sudo livemedia-creator --make-appliance --iso=/path/to/boot.iso --ks=./docs/fedora-minimal.ks \
+    --qcow2 --app-file=minimal-test.xml --image-name=minimal-test.img
+
+
+Filesystem Image Creation
+-------------------------
+
+livemedia-creator can be used to create un-partitined filesystem images using the
+``--make-fsimage`` option. As of version 21.8 this works with both virt-install and no-virt modes
+of operation. Previously it was only available with no-virt.
+
+Kickstarts should have a single / partition with no extra mountpoints.
+
+    ``livemedia-creator --make-fsimage --iso=/path/to/boot.iso --ks=./docs/fedora-minimal.ks``
+
+You can name the output image with ``--image-name`` and set a label on the filesystem with ``--fs-label``
+
+
+TAR File Creation
+-----------------
+
+The ``--make-tar`` command can be used to create a tar of the root filesystem. By
+default it is compressed using xz, but this can be changed using the
+``--compression`` and ``--compress-arg`` options. This option works with both virt and
+no-virt install methods.
+
+As with ``--make-fsimage`` the kickstart should be limited to a single / partition.
+
+For example::
+
+    livemedia-creator --make-tar --iso=/path/to/boot.iso --ks=./docs/fedora-minimal.ks \
+    --image-name=fedora-root.tar.xz
+
+
+Live Image for PXE Boot
+-----------------------
+
+The ``--make-pxe-live`` command will produce squashfs image containing live root
+filesystem that can be used for pxe boot. Directory with results will contain
+the live image, kernel image, initrd image and template of pxe configuration
+for the images.
+
+
+Atomic Live Image for PXE Boot
+------------------------------
+
+The ``--make-ostree-live`` command will produce the same result as ``--make-pxe-live``
+for installations of Atomic Host.  Example kickstart for such an installation
+using Atomic installer iso with local repo included in the image can be found
+in docs/rhel-atomic-pxe-live.ks.
+
+
+Using Mock to Create Images
+---------------------------
+
+As of lorax version 22.2 you can use livemedia-creator and anaconda version
+22.15 inside of a mock chroot with --make-iso and --make-fsimage. Note that
+this requires bind mounting the host's /dev/ directory into the mock, which
+could be dangerous since it includes the host's drives. You can work around
+this by /dev/loopX nodes before running livemedia-creator. This example does
+not do that.
+
+On the host system:
+
+1. yum install -y mock
+
+2. Add a user to the mock group to use for running mock. eg. builder
+
+3. Edit the /etc/mock/site-defaults.cfg file to change:
+
+   ``config_opts['internal_dev_setup'] = False``
+
+   The loop devices are needed for the installation, so it needs to mount the
+   host's /dev/ inside the mock.
+
+   This is fairly dangerous. I would recommend using a dedicated build host and
+   making sure you have backups just in case something goes wrong and it
+   modifies the host system.  You can avoid this if you setup the /dev/loopX
+   device nodes yourself.
+
+4. Create a new /etc/mock/ config file based on the rawhide one, or modify the
+   existing one so that the following options are setup::
+
+       config_opts['chroot_setup_cmd'] = 'install @buildsys-build anaconda-tui lorax'
+
+       # NOTE that this actually needs to be set in site-defaults.cfg
+       config_opts['internal_dev_setup'] = False
+
+       # Mount the relevant host paths inside the mock /dev/
+       config_opts['plugin_conf']['bind_mount_enable'] = True
+       config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/dev','/dev/'))
+       config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/dev/pts','/dev/pts/'))
+       config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/dev/shm','/dev/shm/'))
+
+       # build results go into /home/builder/results/
+       config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/home/builder/results','/results/'))
+
+The following steps are run as the builder user who is a member of the mock
+group.
+
+5. Make a directory for results matching the bind mount above
+   ``mkdir ~/results/``
+
+6. Copy the example kickstarts
+   ``cp /usr/share/docs/lorax/*ks .``
+
+7. Make sure tar and dracut-network are in the %packages section and that the
+   ``url points to the correct repo``
+
+8. Init the mock
+   ``mock -r fedora-rawhide-x86_64 --init``
+
+9. Copy the kickstart inside the mock
+   ``mock -r fedora-rawhide-x86_64 --copyin ./fedora-minimal.ks /root/``
+
+10. Make a minimal iso::
+
+        mock -r fedora-rawhide-x86_64 --chroot -- livemedia-creator --no-virt \
+        --resultdir=/results/try-1 --logfile=/results/logs/try-1/try-1.log \
+        --make-iso --ks /root/fedora-minimal.ks
+
+Results will be in ./results/try-1 and logs under /results/logs/try-1/
+including anaconda logs and livemedia-creator logs. The new iso will be
+located at ~/results/try-1/images/boot.iso, and the ~/results/try-1/
+directory tree will also contain the vmlinuz, initrd, etc.
+
+
+OpenStack Image Creation
+------------------------
+
+OpenStack supports partitioned disk images so ``--make-disk`` can be used to
+create images for importing into glance, OpenStack's image storage component.
+You need to have access to an OpenStack provider that allows image uploads, or
+setup your own using the instructions from the `RDO Project
+<https://www.rdoproject.org/Quickstart>`.
+
+The example kickstart, fedora-openstack.ks, is only slightly different than the
+fedora-minimal.ks one.  It adds the cloud-init and cloud-utils-growpart
+packages. OpenStack supports setting up the image using cloud-init, and
+cloud-utils-growpart will grow the image to fit the instance's disk size.
+
+Create a qcow2 image using the kickstart like this:
+
+    ``sudo livemedia-creator --make-disk --iso=/path/to/boot.iso --ks=/path/to/fedora-openstack.ks --qcow2``
+
+.. note::
+    On the RHEL7 version of lmc ``--qcow2`` isn't supported. You can only create a bare partitioned disk image.
+
+Import the resulting disk image into the OpenStack system, either via the web UI, or glance on the cmdline::
+
+    glance image-create --name "fedora-openstack" --is-public true --disk-format qcow2 \
+    --container-format bare --file ./fedora-openstack.qcow2
+
+If qcow2 wasn't used then ``--disk-format`` should be set to raw.
+
+
+Docker Image Creation
+---------------------
+
+Use lmc to create a tarfile as described in the `TAR File Creation`_ section, but substitute the
+fedora-docker.ks example kickstart which removes the requirement for core files and the kernel.
+
+You can then import the tarfile into docker like this (as root):
+
+    ``cat /var/tmp/fedora-root.tar.xz | docker import - fedora-root``
+
+And then run bash inside of it:
+
+    ``sudo docker run -i -t fedora-root /bin/bash``
+
+
+Debugging problems
+------------------
+
+Sometimes an installation will get stuck. When using virt-install the logs will
+be written to ./virt-install.log and most of the time any problems that happen
+will be near the end of the file. lmc tries to detect common errors and will
+cancel the installation when they happen. But not everything can be caught.
+When creating a new kickstart it is helpful to use the ``--vnc vnc`` command so
+that you can monitor the installation as it happens, and if it gets stuck
+without lmc detecting the problem you can switch to tty1 and examine the system
+directly.
+
+If it does get stuck the best way to cancel is to use virsh to destroy the domain.
+
+1. Use ``sudo virsh list`` to show the name of the virt. It will start with LiveOS and contain a UUID.
+2. Run ``sudo virsh destroy <name>`` to destroy the domain.
+3. Wait 20 seconds or so for lmc to detect that the domain vanished. It should handle cleanup.
+
+If lmc didn't handle the cleanup for some reason you can do this:
+1. ``sudo virsh undefine <name>``
+2. ``sudo umount /tmp/tmpXXXX`` to unmount the iso from its mountpoint.
+3. ``sudo rm -rf /tmp/tmpXXXX``
+4. ``sudo rm /var/tmp/diskXXXXX`` to remove the disk image.
+
+The logs from the virt-install run are stored in virt-install.log,
+logs from livemedia-creator are in livemedia.log and program.log
+
+You can add ``--image-only`` to skip the .iso creation and examine the resulting
+disk image. Or you can pass ``--keep-image`` to keep it around after the iso has
+been created.
+
+Cleaning up aborted ``--no-virt`` installs can sometimes be accomplished by
+running the ``anaconda-cleanup`` script. As of Fedora 18 anaconda is
+multi-threaded and it can sometimes become stuck and refuse to exit. When this
+happens you can usually clean up by first killing the anaconda process then
+running ``anaconda-cleanup``.
+
+
+Hacking
+-------
+
+Development on this will take place as part of the lorax project, and on the
+anaconda-devel-list mailing list, and `on github <https://github.com/rhinstaller/lorax>`_
+
+Feedback, enhancements and bugs are welcome.  You can use `bugzilla
+<https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=lorax>`_ to
+report bugs against the lorax component.
+
diff --git a/docs/lorax.rst b/docs/lorax.rst
new file mode 100644
index 00000000..c43be130
--- /dev/null
+++ b/docs/lorax.rst
@@ -0,0 +1,6 @@
+lorax
+=====
+
+The lorax script executes the templates and create the boot.iso
+
+
diff --git a/docs/modules.rst b/docs/modules.rst
new file mode 100644
index 00000000..cf124f58
--- /dev/null
+++ b/docs/modules.rst
@@ -0,0 +1,7 @@
+src
+===
+
+.. toctree::
+   :maxdepth: 4
+
+   pylorax
diff --git a/README.product b/docs/product-images.rst
similarity index 53%
rename from README.product
rename to docs/product-images.rst
index d1c974de..5ad6cd81 100644
--- a/README.product
+++ b/docs/product-images.rst
@@ -1,3 +1,6 @@
+Product and Updates Images
+==========================
+
 Lorax now supports creation of product.img and updates.img as part of the build
 process. This is implemented using the installimg command which will take the
 contents of a directory and create a compressed archive from it. The x86, ppc,
@@ -6,16 +9,16 @@ ppc64le and aarch64 templates all look for /usr/share/lorax/product/ and
 there are files in those directories lorax will create images/product.img
 and/or images/updates.img
 
-These archives are just like an anaconda updates image -- they are copied over
-the top of the filesystem at boot time so that you can drop in files to add to
-or replace anything on the filesystem.
+These archives are just like an anaconda updates image -- their contents are
+copied over the top of the filesystem at boot time so that you can drop in
+files to add to or replace anything on the filesystem.
 
 Anaconda has several places that it looks for updates, the one for product.img
-is in /run/install/product.  For example, to add an installclass to Anaconda
+is in /run/install/product.  So for example, to add an installclass to Anaconda
 you would put your custom class here:
 
-/usr/share/lorax/product/run/install/product/pyanaconda/installclasses/custom.py
+``/usr/share/lorax/product/run/install/product/pyanaconda/installclasses/custom.py``
 
 If the packages containing the product/updates files are not included as part
-of normal dependencies you can add specific packages with the --installpkgs
-command or the installpkgs paramater of RuntimeBuilder.
+of normal dependencies you can add specific packages with the ``--installpkgs``
+command or the installpkgs paramater of :class:`pylorax.treebuilder.RuntimeBuilder`
diff --git a/docs/pylorax.rst b/docs/pylorax.rst
new file mode 100644
index 00000000..80f686ab
--- /dev/null
+++ b/docs/pylorax.rst
@@ -0,0 +1,110 @@
+pylorax package
+===============
+
+Submodules
+----------
+
+pylorax.base module
+-------------------
+
+.. automodule:: pylorax.base
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.buildstamp module
+-------------------------
+
+.. automodule:: pylorax.buildstamp
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.decorators module
+-------------------------
+
+.. automodule:: pylorax.decorators
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.discinfo module
+-----------------------
+
+.. automodule:: pylorax.discinfo
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.dnfhelper module
+------------------------
+
+.. automodule:: pylorax.dnfhelper
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.executils module
+------------------------
+
+.. automodule:: pylorax.executils
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.imgutils module
+-----------------------
+
+.. automodule:: pylorax.imgutils
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.ltmpl module
+--------------------
+
+.. automodule:: pylorax.ltmpl
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.output module
+---------------------
+
+.. automodule:: pylorax.output
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.sysutils module
+-----------------------
+
+.. automodule:: pylorax.sysutils
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.treebuilder module
+--------------------------
+
+.. automodule:: pylorax.treebuilder
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+pylorax.treeinfo module
+-----------------------
+
+.. automodule:: pylorax.treeinfo
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+
+Module contents
+---------------
+
+.. automodule:: pylorax
+    :members:
+    :undoc-members:
+    :show-inheritance:
diff --git a/lorax.spec b/lorax.spec
index 37c76101..11d162ac 100644
--- a/lorax.spec
+++ b/lorax.spec
@@ -91,7 +91,7 @@ make DESTDIR=$RPM_BUILD_ROOT mandir=%{_mandir} install
 %files
 %defattr(-,root,root,-)
 %license COPYING
-%doc AUTHORS README.livemedia-creator README.product
+%doc AUTHORS docs/livemedia-creator.rst docs/product-images.rst
 %doc docs/*ks
 %{python_sitelib}/pylorax
 %{python_sitelib}/*.egg-info