In terms of QE for this bug, I've re-thought about this, and re-read the upstream bug report [1], and my conclusion is that we can't really QE this on anything other than an 9 -> 10 upgrade. Like Sylvain said [2], we added RequestSpec records in Newton, and an online data migration to add those in the database for instances that were created before the upgrade to Newton and thus didn't have this RequestSpec record. Any instance created after Newton will have that RequestSpect record, and so will be unable to trigger the bug. So we need an instance created in OSP9, without the RequestSpec record, then we upgrade to 10 and run the online data migration. The reason the bug was cloned to OSP11 and 12 is that we needed something to track the database schema backports. I can't think of any situation where it's feasible to QE this other than a 9->10 upgrade, so I'm suggesting we just deploy OSP12 and double check that request_spec is indeed MEDIUMTEXT as verification. [1] https://bugs.launchpad.net/nova/+bug/1707934 [2] https://bugs.launchpad.net/nova/+bug/1707934/comments/1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0241