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 binaries, etc as part of basic output. I'm happy to propose deltas to address (next week at the earliest).
trown
commented
8 years ago
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 binaries, etc as part of basic output. I'm happy to propose deltas to address (next week at the earliest).