Open Stack

----- Original Message -----
> From: "Devananda van der Veen" <devananda.vdv at gmail.com>
> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, May 21, 2014 8:03:15 PM
> 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.

+1

Not claiming the same level of support seems reasonable if we don't have 3rd party CI running on it.

This specific driver is integral to my personal TripleO dev/testing environment and as such I will provide a timely feedback loop on keeping it working. I've been using the same driver in Nova for around a year now and it has proven useful for testing on real baremetal as I'm using machines without IPMI.

> 
> 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...

I believe Nova may have too far... see below.

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

Short answer:

 Because the driver can be easily broken due to internal Ironic driver API changes. :(

Long answer:

 Anyone who has tried to keep a driver in-sync with an OpenStack project out of tree knows how frustrating it can be when internal API's change. These API's don't change often (obviously we try to minimize it) but they do change, often in subtle ways that you might not detect in code review. By remaining in-tree we allow our drivers to be unit tested which can help avoid some of these breakages. These internal interfaces have already changed in Ironic during the review cycle for this branch (see the differences between patches 2 and 3 for example) so having it live in tree would already be useful here.

 With regards to Nova: I think OpenStack as a whole may be going too far with its 3rd party CI rules which force drivers out of tree. As a community I think we might benefit from having both the Ironic and Docker drivers in the Nova tree at this point... regardless of 3rd party CI rules.  We have people in the community who are willing to maintain these drivers, they are very popular, and we are arguably causing ourselves extra work by keeping them out of tree. Now, where they live in tree and what we say about our support for them... that is a very good question. Perhaps they should also live in tree but in a separate directory ('contrib' or 'experimental' works for me). Talking about this here is probably a bit out of scope though because a compute driver is a good bit more complicated than an Ironic power driver is... and would likely require a lot more code, maintenance, etc. I only mention it because I believe we may have got it wrong with Nova... so perhaps we shouldn't repeat the same rules in Ironic?

 In summary: Having a diverse set of power drivers live in Ironic is useful for both users and developers. The changes requiring specific domain knowledge are probably low enough that they won't be an issue. 3rd party CI requirements are desirable, but in many cases the requirements are sufficiently high enough to make them impractical. As an added plus I think the Ironic community reviews help to raise the bar on these drivers in a way that wouldn't happen if they lived out of tree (you guys help make my code better!)

Dan

> 
> 
> -Devananda
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>