[00:03] <powersj> magicalChicken: https://jenkins.ubuntu.com/server/job/cloud-init-integration-x/103/console
[00:04] <powersj> Looks like the qemu migration tests were running at the same time as the integration tests. And the integration tests attempted to delete a snapshot. Why would cii do that?
[03:21] <magicalChicken> powersj: a couple things here...
[03:22] <magicalChicken> the reason the snapshot is being used is as the backend of the 'launch container from existing container' lxd feature
[03:23] <magicalChicken> it looks like there was already an image using one of the ones being cleaned up by the cloud tests
[03:24] <magicalChicken> actually, i guess it was during the image being created originally, not during a launch
[03:24] <magicalChicken> maybe there was a uuid collision between images?
[03:25] <magicalChicken> the old version of the tests have bad logic for naming images, and don't check existing names for uniqueness or use any namespacing, and we had run into collisions once before I on jenkins I think
[03:25] <magicalChicken> the fix is in the merge proposal for the new tests
[03:26] <magicalChicken> also, this could be connected to cloud tests deleting the image it uses by default instead of preserving, maybe it tried to remove an image that was being used by the qemu tests
[03:26] <magicalChicken> my guess is that its a image name collision though, somehow
[03:27] <magicalChicken> in any case, I think the new version of the tests may fix it
[03:27] <magicalChicken> i can try to reproduce the issue otherwise
[03:28] <magicalChicken> the attempted delete was just due to lxd trying to clean things up, the original failure was that an image already existed that it tried to overwrite
[14:18] <smoser> rharper, well it shoudlnt be trying to rename network devices at 'init'
[14:18] <smoser> but only in init-local
[14:45] <rharper> smoser: hrm
[15:17] <smoser> rharper, its to late to run at init time ... networking is already up
[15:17] <rharper> I completely understand
[15:17] <rharper> I don't know why it triggered the rename path a second time
[15:18] <rharper> I'll get a cloud-init.log for your here in a bit
[15:18] <rharper> there are multiple calls to apply_network_config in main ;  I've not sorted out if we're taking a path that this then multiple times
[16:19] <rharper> smoser: http://paste.ubuntu.com/24084999/;  when 'init' runs, it checks the network config, in doing that, it validates that interfaces are named properly, but this time the mac of the interface to be renamed matches a bond; then we attempt to bring it down and fail.  basically with bonding, we have a mac that points to two interfaces (one physical, one virtual (the bond))
[16:20] <smoser> right. i was about to type that. it does try to rename, but should have come up with "nothing to do"
[16:23] <rharper> right, it should
[16:23] <rharper> but when it looks up the interface by mac
[16:23] <rharper> it finds bond0
[16:23] <rharper> for what it thinks is interface0
[16:23] <rharper> which is true; they share a mac due to how bonding works
[16:23] <rharper> so then it thinks it needs to rename bond0 -> interface0
[16:24] <rharper> since we only rename 'physical' interface (we fetch only 'physical' items from the config; however, when we look up the phys interface by mac, we get two answers (bond0, interface0) ;  but it gets bond first (sorting I guess)
[16:25] <rharper> however, we should reject virt interface names when we're looking for interface info for renaming