[openstack-dev] [ironic][qa] How will ironic tests run in tempest?
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
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