Open Stack

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.hellmann at dreamhost.com>
wrote:

> On Fri, May 23, 2014 at 9:49 AM, Dan Prince <dprince at redhat.com> wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Doug Hellmann" <doug.hellmann at dreamhost.com>
> >> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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
> >> <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.
> >
> >
> > 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 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
> >>
> >
> > _______________________________________________
> > 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/839ee561/attachment.html>