I would rather not require operators to change deployment configuration merely because a driver is more or less tested upstream. Communication of our level of confidence in a driver is good, but requiring breaking config file changes (with or without a deprecation period) doesn't seem like a polite mode of communication.
-Deva On Fri, May 23, 2014 at 6:59 AM, Doug Hellmann <doug.hellm...@dreamhost.com> wrote: > On Fri, May 23, 2014 at 9:49 AM, Dan Prince <dpri...@redhat.com> wrote: > > > > > > ----- Original Message ----- > >> From: "Doug Hellmann" <doug.hellm...@dreamhost.com> > >> To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > >> Sent: Thursday, May 22, 2014 3:18:22 PM > >> Subject: Re: [openstack-dev] [Ironic] handling drivers that will not be > third-party tested > >> > >> On Thu, May 22, 2014 at 4:48 AM, Lucas Alvares Gomes > >> <lucasago...@gmail.com> 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 > >> > > >> >> > >> >> 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. > > > > > > While I understand that making it clear to end users is important I also > think the drivers status is metadata and as such shouldn't directly effect > end users. I would rather not have to make *breaking* config file changes > when drivers flip back and forth from being considered experimental by the > community. If we are using endpoints in this fashion some vendors may in > fact prefer their drivers to remain out of tree for stability with regards > to the end user configuration. Honestly if we are forcing users to change > their endpoints based on our classification of their driver we aren't doing > much better than a classname anyways... > > > > So if we prefix drivers (with anything) we should do it with the mindset > that it will be permanent. > > Fair point. Entry points can be registered under multiple names, which > would let us have the old prefixed names as well as unprefixed names, > but you're right that we would have to deprecate the old names over a > period of a few releases. > > Doug > > > > >> > >> Doug > >> > >> > > >> > [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 > >> > > > > _______________________________________________ > > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
