Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
On Wed, 2014-05-21 at 17:03 -0700, Devananda van der Veen 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. 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? So a few months have gone by since this was initially brought up. I've been consistently rebasing the iboot driver patch along to deal with API changes (breakages). The Ironic power driver API, as small as it is, has not proven to be stable yet. As such I'm even more convinced these sorts of drivers benefit from living in-tree where unit tests give us some level of coverage to guard against internal Ironic API breakage. So... why not merge this driver as-is? It already exists in Nova. Furthermore I feel like it is a bit arbitrary to hold up this driver when we already have other 3rd party drivers in the Ironic tree (seamicro for example) where there is no 3rd party CI. The comments on this list seemed to support having these drivers live in-tree regardless of 3rd party CI. Dan -Devananda ___ 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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
Thanks for putting this back on my radar I think a separate directory to indicate these are contributed but less tested drivers is a fair middle ground here, though time will tell how much addtitional code-maintenance burden that places on developers. Since this is just a power interface, I agree that the burden in this case is small. FWIW, that API is about to get one more method added to it ( https://review.openstack.org/#/c/102914/). Since no one's proposed a /contrib/ directory yet, I'm doing so now, and moving other drivers that lack upstream CI testing to it. This may not be the most elegant solution; it won't require any operational config changes, but only separates drivers into two classes, main and contrib. -Devananda On Thu, Jul 10, 2014 at 6:31 AM, Dan Prince dpri...@redhat.com wrote: On Wed, 2014-05-21 at 17:03 -0700, Devananda van der Veen 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. 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? So a few months have gone by since this was initially brought up. I've been consistently rebasing the iboot driver patch along to deal with API changes (breakages). The Ironic power driver API, as small as it is, has not proven to be stable yet. As such I'm even more convinced these sorts of drivers benefit from living in-tree where unit tests give us some level of coverage to guard against internal Ironic API breakage. So... why not merge this driver as-is? It already exists in Nova. Furthermore I feel like it is a bit arbitrary to hold up this driver when we already have other 3rd party drivers in the Ironic tree (seamicro for example) where there is no 3rd party CI. The comments on this list seemed to support having these drivers live in-tree regardless of 3rd party CI. Dan -Devananda ___ 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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
On Thu, Jul 10, 2014 at 11:21 AM, Devananda van der Veen devananda@gmail.com wrote: Thanks for putting this back on my radar I think a separate directory to indicate these are contributed but less tested drivers is a fair middle ground here, though time will tell how much addtitional code-maintenance burden that places on developers. Since this is just a power interface, I agree that the burden in this case is small. FWIW, that API is about to get one more method added to it ( https://review.openstack.org/#/c/102914/). Since no one's proposed a /contrib/ directory yet, I'm doing so now, and moving other drivers that lack upstream CI testing to it. This may not be the most elegant solution; it won't require any operational config changes, but only separates drivers into two classes, main and contrib. Now with the link to the review :) https://review.openstack.org/106135 -Devananda On Thu, Jul 10, 2014 at 6:31 AM, Dan Prince dpri...@redhat.com wrote: On Wed, 2014-05-21 at 17:03 -0700, Devananda van der Veen 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. 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? So a few months have gone by since this was initially brought up. I've been consistently rebasing the iboot driver patch along to deal with API changes (breakages). The Ironic power driver API, as small as it is, has not proven to be stable yet. As such I'm even more convinced these sorts of drivers benefit from living in-tree where unit tests give us some level of coverage to guard against internal Ironic API breakage. So... why not merge this driver as-is? It already exists in Nova. Furthermore I feel like it is a bit arbitrary to hold up this driver when we already have other 3rd party drivers in the Ironic tree (seamicro for example) where there is no 3rd party CI. The comments on this list seemed to support having these drivers live in-tree regardless of 3rd party CI. Dan -Devananda ___ 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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
Apologies for a late response. I agree, it’s an unfortunate aspect of Ironic’s hardware-focused role in the project that means CI test coverage is hard to achieve. And it is misleading to present our drivers as continuously tested when they are not. Nevertheless, I add a +1 in favour of keeping the drivers within Ironic’s tree. Testing may be only on a best-effort basis, but taking drivers out of tree would result in an Ironic that by default would only support hardware fitting the profile of the test systems, and that could be quite limiting. Can we combine the segregation of untested/unmaintained/unloved drivers with counterbalancing efforts to promote better testing, maintenance and status on third party drivers? For example: - Promotion of third party CI testing within Ironic - Associating a maintainer with each driver - On each release cycle compiling a support matrix of driver status, based on data submitted by the driver maintainers, or face relegation from the table I have seen pages on third party CI and Gerrit’s interface to support this, but I found nothing specific about Ironic driver contributors making use of this. Is there anyone out there who has done this and can comment on their experience? Best wishes, Stig Telfer Cray From: Devananda van der Veen [mailto:devananda@gmail.com] Sent: Thursday, May 22, 2014 1:03 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Ironic] handling drivers that will not be third-party tested 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. 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? -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
- 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. 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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
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? [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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
On Thu, May 22, 2014 at 1:48 AM, Lucas Alvares Gomes lucasago...@gmail.comwrote: 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? [1] http://lwn.net/Articles/285599/ Linux has a very different model then OpenStack does, the article you mention is talking about a whole separate git repo, along with a separate (re: just OR, not exclusive or) set of maintainers. If you leave these drivers in a staging directory would you still require two cores for the code to land? Would this be a bandwidth burden (It can be in nova)? On a related note, Ironic has one similarity the linux that most other OpenStack projects don't have: Testing drivers requires specific hardware. Because of this linux doesn't claim to test every driver in the kernel, if they did they would have a pretty impressive collection of hardware lying around. 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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
Linux has a very different model then OpenStack does, the article you mention is talking about a whole separate git repo, along with a separate (re: just OR, not exclusive or) set of maintainers. If you leave these drivers in a staging directory would you still require two cores for the code to land? Would this be a bandwidth burden (It can be in nova)? Yes Linux has a different model and I'm not proposing us to do the same thing as they do, I just pointed out that what I'm proposing here is slightly similar. Sorry about the article, it was a bad reference. The staging dir lives within the Linux kernel tree[1], perhaps this reference would be better: http://www.kroah.com/log/linux/linux-staging-update.html About the review, I would say that yes the 2 +2 approach should work the same for those drivers just like any other patch in the queue and If it's become a burden we can always expand the core team. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging Cheers, Lucas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
- Original Message -
From: Devananda van der Veen devananda@gmail.com
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Sent: Wednesday, May 21, 2014 8:03:15 PM
Subject: [openstack-dev] [Ironic] handling drivers that will not be
third-party tested
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
Not claiming the same level of support seems reasonable if we don't have 3rd
party CI running on it.
This specific driver is integral to my personal TripleO dev/testing environment
and as such I will provide a timely feedback loop on keeping it working. I've
been using the same driver in Nova for around a year now and it has proven
useful for testing on real baremetal as I'm using machines without IPMI.
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...
I believe Nova may have too far... see below.
So, why not just put the driver in a separate library on github or
stackforge?
Short answer:
Because the driver can be easily broken due to internal Ironic driver API
changes. :(
Long answer:
Anyone who has tried to keep a driver in-sync with an OpenStack project out of
tree knows how frustrating it can be when internal API's change. These API's
don't change often (obviously we try to minimize it) but they do change, often
in subtle ways that you might not detect in code review. By remaining in-tree
we allow our drivers to be unit tested which can help avoid some of these
breakages. These internal interfaces have already changed in Ironic during the
review cycle for this branch (see the differences between patches 2 and 3 for
example) so having it live in tree would already be useful here.
With regards to Nova: I think OpenStack as a whole may be going too far with
its 3rd party CI rules which force drivers out of tree. As a community I think
we might benefit from having both the Ironic and Docker drivers in the Nova
tree at this point... regardless of 3rd party CI rules. We have people in the
community who are willing to maintain these drivers, they are very popular, and
we are arguably causing ourselves extra work by keeping them out of tree. Now,
where they live in tree and what we say about our support for them... that is a
very good question. Perhaps they should also live in tree but in a separate
directory ('contrib' or 'experimental' works for me). Talking about this here
is probably a bit out of scope though because a compute driver is a good bit
more complicated than an Ironic power driver is... and would likely require a
lot more code, maintenance, etc. I only mention it because I believe we may
have got it wrong with Nova... so perhaps we shouldn't repeat
the same rules in Ironic?
In summary: Having a diverse set of power drivers live in Ironic is useful for
both users and developers. The changes requiring specific domain knowledge are
probably low enough that they won't be an issue. 3rd party CI requirements are
desirable, but in many cases the requirements are sufficiently high enough to
make them impractical. As an added plus I think the Ironic community reviews
help to raise the bar on these drivers in a way that wouldn't happen if they
lived out of tree (you guys help make my code better!)
Dan
-Devananda
___
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
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
On Thu, May 22, 2014 at 9:05 AM, Dan Prince dpri...@redhat.com wrote: - Original Message - From: Devananda van der Veen devananda@gmail.com [...] 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. Not claiming the same level of support seems reasonable if we don't have 3rd party CI running on it. As was repeated many times last week: if it isn't tested it is broken. We get to argue over the definition and degree of 'tested' now... So, why not just put the driver in a separate library on github or stackforge? Because the driver can be easily broken due to internal Ironic driver API changes. :( I have similar issues with DevStack and including in-repo support for drivers/projects that are not integrated or incubated or even an OpenStack-affiliated project at all. And have come to the conclusion that at some point some things just make sense to include anyway. But the different status needs to be communicated somehow. As a user of an open source project it is frustrating for me to want/need to use something in a 'contrib' directory and not be able to know if that thing still works or if it is even maintained. Having a certain amount of testing to at least demonstrate non-brokenness should be a requirement for inclusion. It would be great if we would adopt common nomenclature here so user expectations are consistent: * 'experimental' - stuff not tested at all? * 'contrib' - stuff with some amount of testing short of gating * 'thirdparty' - stuff that requires hardware or licensed software to fully test Also, contact information should be required for anything 'special' to at least know who to notify if the thing is so broken that removal is contemplated. Projects are going to do what they want regarding inclusion/exclusion policies, I hope we can use common practices to implement those choices. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. 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] [Ironic] handling drivers that will not be third-party tested
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. 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? -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] handling drivers that will not be third-party tested
+1 for community contribs and a common place for them to be sourced. From: Devananda van der Veen [mailto:devananda@gmail.com] Sent: Wednesday, May 21, 2014 5:03 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Ironic] handling drivers that will not be third-party tested 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. 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? -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
