[openstack-dev] [ironic][qa] How will ironic tests run in tempest?

Jay Pipes jaypipes at gmail.com
Tue Dec 10 16:42:04 UTC 2013

On 12/09/2013 01:37 PM, Devananda van der Veen wrote:
> On Fri, Dec 6, 2013 at 2:13 PM, Clark Boylan <clark.boylan at gmail.com
> <mailto:clark.boylan at gmail.com>> wrote:
> We can test the ironic services, database, and the driver interfaces by
> using our "fake" driver within a single devstack VM today (I'm not sure
> the exercises for all of this have been written yet, but it's practical
> to test it). OTOH, I don't believe we can test a PXE deploy within a
> single VM today, and need to resume discussions with infra about this.

FWIW, this is the main issue that we have struggled to overcome in our 
continuous testing process here at AT&T for the better part of 18 
months. It is exceedingly difficult to test bare-metal setup of RAID, 
network interface configuration, partitioning, and other such stuffs in 
a deployment gate.

We eventually moved on to work on other things that, frankly, gave us 
much more bang for the proverbial buck than testing raw bare-metal 
configuration -- things like our OpenStack and infrastructure services 
Chef cookbooks. The reason I say that the bare-metal testing didn't give 
us as much bang for the buck is because the bare-metal configuration 
was, frankly, something we do very seldom -- usually just once when a 
deployment is initialized. Changes to bare-metal base configuration of 
RAID, network interfaces, and partitioning, are exceedingly rare; really 
thing change only when vendors screw up or we need to deal with a 
different set of hardware. Comparatively, OpenStack projects (installed 
and configured with our Chef cookbooks) change at a rapid pace, bugs are 
fixed and features are added continually. Therefore, it makes much more 
sense to focus our "iterative testing loop" on the things that change 
the most and provide the most benefit.

> There are some other aspects of Ironic (IPMI, SOL access, any
> vendor-specific drivers) which we'll need real hardware to test because
> they can't effectively be virtualized. TripleO should cover some (much?)
> of those needs, once they are able to switch to using Ironic instead of
> nova-baremetal.

I'm very interested in how Triple-O will innovate in this space in the 
next year or so. The promise of a continually-delivered bare-metal 
undercloud is one thing. The promise of having a fully-automated "Metal 
as a Service" is another. I suspect it is the latter promise that most 
product people are salivating over right now.


More information about the OpenStack-dev mailing list