<div dir="ltr">Hello Jim,<br><br><div class="gmail_extra">Thanks for rising this question.<br><br></div><div class="gmail_extra">My personal feeling that we don't need to tune tests that won't pass due to design limitations.<br></div><div class="gmail_extra">It is Ironic pre-requirement to have network access from control plane to server during provisioning.<br></div><div class="gmail_extra">Until Ironic Neutron integration is completed we may skip this test. <br><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, May 12, 2016 at 12:53 AM, Jim Rollenhagen <span dir="ltr"><<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've ran into a bit of a wedge working on ironic grenade tests.<br>
<br>
In a normal dsvm run, the ironic setup taps the control plane into the<br>
tenant network (as that's how it's currently intended to be deployed).<br>
That code is here[0].<br>
<br>
However, in a grenade run, during the resource create phase, a new<br>
network is created. This happens in the neutron bits[1], and is used to<br>
boot a server in the nova bits[2].<br>
<br>
Since the control plane can't communicate with the machine on that<br>
network, our ramdisk doesn't reach back to ironic after booting up, and<br>
provisioning fails[3][4].<br>
<br>
Curious if any grenade experts have thoughts on how we might be able to<br>
set up that tap in between the neutron and nova resource creation.<br>
<br>
One alternative I've considered is a method to have nova resource<br>
creation not boot an instance, and replicate that functionality in the<br>
ironic plugin, after we tap into that network.<br>
<br>
I'm sure there's other alternatives here that I haven't thought of;<br>
suggestions welcome. Thanks in advance. :)<br>
<br>
// jim<br>
<br>
[0] <a href="https://github.com/openstack/ironic/blob/95ff5badbdea0898d7877e651893916008561760/devstack/lib/ironic#L653" rel="noreferrer" target="_blank">https://github.com/openstack/ironic/blob/95ff5badbdea0898d7877e651893916008561760/devstack/lib/ironic#L653</a><br>
[1] <a href="https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cddd620e3f03684a/projects/50_neutron/resources.sh#L34" rel="noreferrer" target="_blank">https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cddd620e3f03684a/projects/50_neutron/resources.sh#L34</a><br>
[2] <a href="https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cddd620e3f03684a/projects/60_nova/resources.sh#L79" rel="noreferrer" target="_blank">https://github.com/openstack-dev/grenade/blob/fce63f40d21abea926d343e9cddd620e3f03684a/projects/60_nova/resources.sh#L79</a><br>
[3] <a href="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" rel="noreferrer" target="_blank">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</a><br>
[4] <a href="http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-ironic/e635dec/logs/old/screen-ir-cond.txt.gz?level=WARNING" rel="noreferrer" target="_blank">http://logs.openstack.org/65/311865/3/experimental/gate-grenade-dsvm-ironic/e635dec/logs/old/screen-ir-cond.txt.gz?level=WARNING</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>