----- Original Message -----
> From: "Devananda van der Veen" <devananda....@gmail.com>
> To: "OpenStack Development Mailing List" <openstack-dev@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
