Open Stack

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