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 <dtant...@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....@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@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 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
