6c394f5746
Currently we only export "image-block-device" which is the loopback device (/dev/loopX) for the underlying image. This is the device we install grub to (from inside the chroot ...) This is ok for x86, but is insufficient for some platforms like PPC which have a separate boot partition. They do not want to install to the loop device, but do things like dd special ELF files into special boot partitions. The first problem seems to be that in level1/partitioning.py we have a whole bunch of different paths that either call partprobe on the loop device, or kpartx. We have _all_part_devices_exist() that gates the kpartx for unknown reasons. We have detach_loopback() that does not seem to remove losetup created devices. I don't think this does cleanup if it uses kpartx correctly. It is extremley unclear what's going to be mapped where. This moves to us *only* using kpartx to map the partitions of the loop device. We will *not* call partprobe and create the /dev/loopXpN devices and will only have the devicemapper nodes kpartx creates. This seems to be best. Cleanup happens inside partitioning.py. practice. Deeper thinking about this, and more cleanup of the variables will be welcome. This adds "image-block-devices" (note the extra "s") which exports all the block devices with name and path. This is in a string format that can be eval'd to an array (you can't export arrays). This is then used in a follow-on (I0918e8df8797d6dbabf7af618989ab7f79ee9580) to pick the right partition on PPC. Change-Id: If8e33106b4104da2d56d7941ce96ffcb014907bc |
||
---|---|---|
bin | ||
diskimage_builder | ||
doc | ||
releasenotes | ||
tests | ||
.gitignore | ||
.gitreview | ||
.testr.conf | ||
babel.cfg | ||
bindep.txt | ||
LICENSE | ||
pylint.cfg | ||
README.rst | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
Image building tools for OpenStack
diskimage-builder
is a flexible suite of components for
building a wide-range of disk images, filesystem images and ramdisk
images for use with OpenStack.
This repository has the core functionality for building such images, both virtual and bare metal. Images are composed using elements; while fundamental elements are provided here, individual projects have the flexibility to customise the image build with their own elements.
For example:
$ DIB_RELEASE=trusty disk-image-create -o ubuntu-trusty.qcow2 vm ubuntu
will create a bootable Ubuntu Trusty based qcow2
image.
diskimage-builder
is useful to anyone looking to produce
customised images for deployment into clouds. These tools are the
components of TripleO that are
responsible for building disk images. They are also used extensively to
build images for testing OpenStack itself, particularly with nodepool.
Platforms supported include Ubuntu, CentOS, RHEL and Fedora.
Full documentation, the source of which is in
doc/source/
, is published at:
Copyright
Copyright 2012 Hewlett-Packard Development Company, L.P. Copyright (c) 2012 NTT DOCOMO, INC.
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.