Open Stack

Apologies for a late response. I agree, it’s an unfortunate aspect of Ironic’s hardware-focused role in the project that means CI test coverage is hard to achieve.  And it is misleading to present our drivers as continuously tested when they are not.

Nevertheless, I add a +1 in favour of keeping the drivers within Ironic’s tree.  Testing may be only on a best-effort basis, but taking drivers out of tree would result in an Ironic that by default would only support hardware fitting the profile of the test systems, and that could be quite limiting.

Can we combine the segregation of untested/unmaintained/unloved drivers with counterbalancing efforts to promote better testing, maintenance and status on third party drivers?  For example:


-          Promotion of third party CI testing within Ironic

-          Associating a maintainer with each driver

-          On each release cycle compiling a support matrix of driver status, based on data submitted by the driver maintainers, or face relegation from the table

I have seen pages on third party CI and Gerrit’s interface to support this, but I found nothing specific about Ironic driver contributors making use of this.  Is there anyone out there who has done this and can comment on their experience?

Best wishes,
Stig Telfer
Cray


From: Devananda van der Veen [mailto:devananda.vdv at gmail.com]
Sent: Thursday, May 22, 2014 1:03 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Ironic] handling drivers that will not be third-party tested

I'd like to bring up the topic of drivers which, for one reason or another, are probably never going to have third party CI testing.

Take for example the iBoot driver proposed here:
  https://review.openstack.org/50977

I would like to encourage this type of driver as it enables individual contributors, who may be using off-the-shelf or home-built systems, to benefit from Ironic's ability to provision hardware, even if that hardware does not have IPMI or another enterprise-grade out-of-band management interface. However, I also don't expect the author to provide a full third-party CI environment, and as such, we should not claim the same level of test coverage and consistency as we would like to have with drivers in the gate.

As it is, Ironic already supports out-of-tree drivers. A python module that registers itself with the appropriate entrypoint will be made available if the ironic-conductor service is configured to load that driver. For what it's worth, I recall Nova going through a very similar discussion over the last few cycles...

So, why not just put the driver in a separate library on github or stackforge?


-Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140606/843729db/attachment.html>