<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 10, 2014 at 11:21 AM, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Thanks for putting this back on my radar....</div>
<div><br></div><div>I think a separate directory to indicate "these are contributed but less tested drivers" is a fair middle ground here, though time will tell how much addtitional code-maintenance burden that places on developers. Since this is just a power interface, I agree that the burden in this case is small. FWIW, that API is about to get one more method added to it (<a href="https://review.openstack.org/#/c/102914/" target="_blank">https://review.openstack.org/#/c/102914/</a>).</div>
<div><br></div><div>Since no one's proposed a /contrib/ directory yet, I'm doing so now, and moving other drivers that lack upstream CI testing to it. This may not be the most elegant solution; it won't require any operational config changes, but only separates drivers into two classes, "main" and "contrib".</div>
<span class=""><font color="#888888">
<div><br></div></font></span></div></blockquote><div><br></div><div>Now with the link to the review :)</div><div> <a href="https://review.openstack.org/106135">https://review.openstack.org/106135</a></div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><font color="#888888"><div>
</div><div>-Devananda</div><div><br></div></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 10, 2014 at 6:31 AM, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Wed, 2014-05-21 at 17:03 -0700, Devananda van der Veen wrote:<br>
> I'd like to bring up the topic of drivers which, for one reason or<br>
> another, are probably never going to have third party CI testing.<br>
><br>
><br>
> Take for example the iBoot driver proposed here:<br>
> <a href="https://review.openstack.org/50977" target="_blank">https://review.openstack.org/50977</a><br>
><br>
><br>
> I would like to encourage this type of driver as it enables individual<br>
> contributors, who may be using off-the-shelf or home-built systems, to<br>
> benefit from Ironic's ability to provision hardware, even if that<br>
> hardware does not have IPMI or another enterprise-grade out-of-band<br>
> management interface.<br>
> However, I also don't expect the author to provide a full third-party<br>
> CI environment, and as such, we should not claim the same level of<br>
> test coverage and consistency as we would like to have with drivers in<br>
> the gate.<br>
><br>
><br>
> As it is, Ironic already supports out-of-tree drivers. A python module<br>
> that registers itself with the appropriate entrypoint will be made<br>
> available if the ironic-conductor service is configured to load that<br>
> driver. For what it's worth, I recall Nova going through a very<br>
> similar discussion over the last few cycles...<br>
><br>
><br>
> So, why not just put the driver in a separate library on github or<br>
> stackforge?<br>
<br>
</div></div>So a few months have gone by since this was initially brought up. I've<br>
been consistently rebasing the iboot driver patch along to deal with API<br>
changes (breakages). The Ironic power driver API, as small as it is, has<br>
not proven to be stable yet. As such I'm even more convinced these sorts<br>
of drivers benefit from living in-tree where unit tests give us some<br>
level of coverage to guard against internal Ironic API breakage.<br>
<br>
So... why not merge this driver as-is? It already exists in Nova.<br>
Furthermore I feel like it is a bit arbitrary to hold up this driver<br>
when we already have other 3rd party drivers in the Ironic tree<br>
(seamicro for example) where there is no 3rd party CI.<br>
<br>
The comments on this list seemed to support having these drivers live<br>
in-tree regardless of 3rd party CI.<br>
<br>
Dan<br>
<br>
><br>
><br>
><br>
><br>
> -Devananda<br>
<div><div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>