On 12/09/2013 01:37 PM, Devananda van der Veen wrote:
On Fri, Dec 6, 2013 at 2:13 PM, Clark Boylan <clark.boy...@gmail.com <mailto:clark.boy...@gmail.com>> wrote:
<snip>
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.
Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
