action #105079
Updated by JERiveraMoya about 2 years ago
Even by collecting as many logs as we can, we often face the lack of something. In the world of support, some companies take a radical approach to this. For example, Solaris used to have a tool that would snapshot the entire OS, that could be uploaded to support, so the support team could navigate through a tarball containing literally the entire OS. It takes some storage space, but can spare a huge amount of time: - going back and forth between customer and support for requesting specific logs, - rebuilding a system with the same characteristics etc... In some cases, we already export a qcow image at the end en of installation, which can be used to reproduce bugs. But this does not represent the system at the time of failure. Qemu has snapshot capabilities that could make it possible to boot the system right after its failure. This could complement or partially replace the current log collection mechanisms. Currently we have MAKETESTSNAPSHOTS Save snapshot for each test module in qcow image and PUBLISH_HDD_N. AC1: Test manually how to use those qemu qcow2 that have multiple snapshots AC2: Communicate with tools team on the possibility possiblity of having published a qcow2 just adding some openQA setting to be able to rerun the job and publish on failure. doing this. AC3: AC2: Make a proposal of implementation and create follow-up ticket.