Comment 18 for bug 1665698

Hi Christian,

I have not tested the workaround yet. What I have done since I posted this was tried to narrow it down to the specific nova commit that I suspected triggered this. To be specific, I am deploying Newton using OpenStack-Ansible.

OSA pulls nova directly from upstream openstack git sources and does not consume Ubuntu Cloud Archive for that. However, the libvirt installed is sourced from UCA. For OSA newton on trusty, libvirt is sourced from UCA's trusty/mitaka repo. For OSA newton on xenial, libvirt comes from UCA xenial/newton.

Without changing the libvirt being installed, I have confirmed the specific nova change that triggers this is https://review.openstack.org/#/c/425637/. The guest xml that nova generates when this commit is applied is in the OP (http://cdn.pasteraw.com/b3tw4cjefomfi3e9k09hvodrfun85z). When I revert my nova SHA to the parent commit of this change, b51231c638228f67ab130a7855b9143b202733f6, without changing any libvirt bits, the VMs launch as expected since they now contain the "<script path=''/>" bits in the network interface xml.

Without digging in to libvirt too much, it seems like it should be fairly easy to reproduce by installing the latest xenial/newton or trusty/mitaka UCA sourced libvirt, and launching a VM with not "<script path=''/>" XML on the ethernet vif.

I am limited on how much time I can commit to testing other changes at this time, but I will try to test the workaround and/or the previous libvirt version you suggested asap. Hopefully this will help fill in the blanks but if you have any other questions I missed let me know!