f60dd38482
This adds a devstack-inspired output filter to standardise timestamping. Currently, python tools timestamp always (timestamp setup in logging_config.py) but all the surrounding bash does not. We have extra timestamps added in run_functests.sh for our own purposes to get the bash timestamps; but this ends up giving us double-timestamps for the python bits. Additionally, callers such as nodepool capture our output and put their own timestamps on it, and again have the double-timestamps. This uses a lightly modified outfilter.py from devstack to standardise this. All output is run through this filter, which will timestamp it. I have removed the places where we double-timestamp -- logging_config.py and the prefix in dib-run-parts. An env option is added to turn timestamps off completely (does not seem worth taking up a command-line option for). For callers like nodepool, they can set this and will just have their own timestamps as they collect the lines. Since all logging is going through outfilter, it's easy to add a --logfile option. I think this will be quite handy; personally I'm always redirecting dib runs to files for debugging. I've also added a "quiet" option. I think this could be useful in run_tests.sh if we were to start logging the output of each test to individual files. This would be much easier to deal with than the very large log files we get (especially if we wanted to turn on parallel running...) Change-Id: I202e1cb200bde17f6d7770cf1e2710bbf4cca64c |
||
|---|---|---|
| bin | ||
| diskimage_builder | ||
| doc | ||
| releasenotes | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| LICENSE | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| pylint.cfg | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
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 ubuntuwill 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.