[openstack-dev] [Ironic] handling drivers that will not be third-party tested
Doug Hellmann
doug.hellmann at dreamhost.com
Thu May 22 19:18:22 UTC 2014
On Thu, May 22, 2014 at 4:48 AM, Lucas Alvares Gomes
<lucasagomes at gmail.com> 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
>
>>
>> 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.
>
> 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.
>
> Thoughts?
One aspect of the entry points-based plugin system is that the
deployer configuring the driver no longer needs to know where the
source lives in the tree to activate it, since the plugin has a name
that is separate from its module or class name. That has 2
implications: It doesn't really matter where in the tree you put the
code, and you need to do something else to document its status.
If you keep the drivers in tree, you may want to consider prefixing
the names of less-well-tested drivers with "contrib-" or
"experimental-" or something similar so the driver's status is clear
at the point when someone goes to activate the driver.
Doug
>
> [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
More information about the OpenStack-dev
mailing list