I've ran into a bit of a wedge working on ironic grenade tests. In a normal dsvm run, the ironic setup taps the control plane into the tenant network (as that's how it's currently intended to be deployed). That code is here[0]. However, in a grenade run, during the resource create phase, a new network is created. This happens in the neutron bits[1], and is used to boot a server in the nova bits[2]. Since the control plane can't communicate with the machine on that network, our ramdisk doesn't reach back to ironic after booting up, and provisioning fails[3][4]. Curious if any grenade experts have thoughts on how we might be able to set up that tap in between the neutron and nova resource creation. One alternative I've considered is a method to have nova resource creation not boot an instance, and replicate that functionality in the ironic plugin, after we tap into that network. I'm sure there's other alternatives here that I haven't thought of; suggestions welcome. Thanks in advance. :) // jim [0] https://github.com/openstack/ironic/blob/95ff5badbdea0898d7877e651893916008561760/devstack/lib/ironic#L653 [1] https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cddd620e3f03684a/projects/50_neutron/resources.sh#L34 [2] https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cddd620e3f03684a/projects/60_nova/resources.sh#L79 [3] http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-ironic/e635dec/logs/grenade.sh.txt.gz#_2016-05-10_18_10_03_648 [4] http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-ironic/e635dec/logs/old/screen-ir-cond.txt.gz?level=WARNING