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

Jim Rollenhagen jim at jimrollenhagen.com
Thu May 12 11:49:45 UTC 2016


On Thu, May 12, 2016 at 10:51:57AM +0300, Vasyl Saienko wrote:
> Hello Jim,
> 
> Thanks for rising this question.
> 
> My personal feeling that we don't need to tune tests that won't pass due to
> design limitations.
> It is Ironic pre-requirement to have network access from control plane to
> server during provisioning.
> Until Ironic Neutron integration is completed we may skip this test.

Well, this isn't a tempest test or anything we can just skip. This is
part of grenade's workflow to do upgrades. It goes:

* run smoke tests on $old
* create some resources to persist across upgrades (this ensures we
  don't break existing resources when upgrading)
* upgrade to $new
* run more tempest tests

We can't just skip the resource create phase here.

// jim

> 
> On Thu, May 12, 2016 at 12:53 AM, Jim Rollenhagen <jim at jimrollenhagen.com>
> 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
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list