halcyondude
commented
8 years ago Update, as it's been a while.
- https://review.gerrithub.io/#/c/276629/ addresses part of this, as we're now capturing log files from the various steps of the build process, bundling them, and co-locating with the images produced.
- When https://review.gerrithub.io/#/c/277420/ lands the logs + images are copied out (if enabled).
- since this issue was logged, we're now using tripleo-common to wrap DIB, and the output (which was the most verbose) is now captured to a file. It's still not an awesome experience but it's no longer thousands of lines --> stdout --> ansible task output.
- have been exploring wiring in ARA
- CI jobs have been using collect-logs. Considering moving logs --> /var/log (or another standard location) so it just picks them up, instead of needing to have collect-logs go searching for them in artib_working_dir. It sounds like a minor/subtle point, but the way we're dealing with logging in RDO and downstream CI it's necessary.
Moved over from: https://github.com/redhat-openstack/tripleo-quickstart/issues/53
Currently the output from the playbook that builds images is a bit of a land-mine. In the case of the output from DIB when it creates the overcloud image, it ends up being > 400,000 characters on a single line. This literally makes Atom, Emacs, PyCharm, Gedit, Kate, VIM, etc go into a death loop trying to parse the line. If one waits far longer than I have patience for (minutes) eventually you'll get back. Interim solutions are to not use the ansible output directly, rather passing it thru sed first to turn \n into \n, open the logfile that's captured, etc. It's a low priority issue, but the first time it happened to me I thought "Ouch...that hurt..." As this project catches on I think anything that increases friction for developers / newcomers should where possible be fixed. In addition, it would be pretty cool to have a nice summary of what was built, the source of the