[openstack-dev] [Ironic] handling drivers that will not be third-party tested

Sergey Lukjanov slukjanov at mirantis.com
Thu May 22 11:35:56 UTC 2014


IMO the separated did in the project repo is a good approach (like
contrib dir in Heat).

On Thu, May 22, 2014 at 3:13 PM, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> On Thu, 2014-05-22 at 09:48 +0100, Lucas Alvares Gomes wrote:
>> On Thu, May 22, 2014 at 1:03 AM, Devananda van der Veen
>> <devananda.vdv at gmail.com> 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.
>>
>> +1
> But we'll still expect unit tests that work via mocking their 3rd party
> library (for example), right?
>
>>
>> >
>> > 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?
>>
>> I would like to have this drivers within the Ironic tree under a
>> separated directory (e.g /drivers/staging/, not exactly same but kinda
>> like what linux has in their tree[1]). The advatanges of having it in
>> the main ironic tree is because it makes it easier to other people
>> access the drivers, easy to detect and fix changes in the Ironic code
>> that would affect the driver, share code with the other drivers, add
>> unittests and provide a common place for development.
> I do agree, that having these drivers in-tree would make major changes
> much easier for us (see also above about unit tests).
>
>>
>> We can create some rules for people who are thinking about submitting
>> their driver under the staging directory, it should _not_ be a place
>> where you just throw the code and forget it, we would need to agree
>> that the person submitting the code will also babysit it, we also
>> could use the same process for all the other drivers wich wants to be
>> in the Ironic tree to be accepted which is going through ironic-specs.
> +1
>
>>
>> Thoughts?
>>
>> [1] http://lwn.net/Articles/285599/
>>
>> Cheers,
>> Lucas
>>
>> _______________________________________________
>> 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



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.



More information about the OpenStack-dev mailing list