Open Stack

On Thu, Jul 10, 2014 at 11:21 AM, Devananda van der Veen <
devananda.vdv at gmail.com> wrote:

> Thanks for putting this back on my radar....
>
> 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 (
> https://review.openstack.org/#/c/102914/).
>
> 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".
>
>
Now with the link to the review :)
    https://review.openstack.org/106135



> -Devananda
>
>
>
> On Thu, Jul 10, 2014 at 6:31 AM, Dan Prince <dprince at redhat.com> wrote:
>
>> On Wed, 2014-05-21 at 17:03 -0700, Devananda van der Veen wrote:
>> > 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?
>>
>> So a few months have gone by since this was initially brought up. I've
>> been consistently rebasing the iboot driver patch along to deal with API
>> changes (breakages). The Ironic power driver API, as small as it is, has
>> not proven to be stable yet. As such I'm even more convinced these sorts
>> of drivers benefit from living in-tree where unit tests give us some
>> level of coverage to guard against internal Ironic API breakage.
>>
>> So... why not merge this driver as-is? It already exists in Nova.
>> Furthermore I feel like it is a bit arbitrary to hold up this driver
>> when we already have other 3rd party drivers in the Ironic tree
>> (seamicro for example) where there is no 3rd party CI.
>>
>> The comments on this list seemed to support having these drivers live
>> in-tree regardless of 3rd party CI.
>>
>> Dan
>>
>> >
>> >
>> >
>> >
>> > -Devananda
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140710/684f8e56/attachment.html>