[openstack-dev] [ironic][nova][neutron][qa] Injecting code into grenade resource create phase

Sean Dague sean at dague.net
Thu May 12 10:48:02 UTC 2016

On 05/11/2016 05:53 PM, Jim Rollenhagen wrote:
> 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

Let me make sure I understand the crux of the issue: services may need
to create additional custom networking in order for the rest of the
resource flow to work correctly. Ironic definitely needs this because
it's building up an interesting simulated network here for it's guests
to live on.

That feels like we need a new pre_create (or early_create) phase that
ironic could hook into to do that same network create. I think the only
question in my mind is whether neutrons network create here should move
to early_create as well.

Does ironic's ovs setup need to happen after the neutron create phase
here, or does it just need to happen before nova?

Does ironic need to overwrite the $net_id that gets passed to Nova later?


Sean Dague

More information about the OpenStack-dev mailing list