Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-03-07 Thread Devananda van der Veen
On Sun, Mar 1, 2015 at 8:45 AM, Clint Byrum wrote: > Excerpts from Gary Kotton's message of 2015-03-01 02:32:37 -0800: >> Hi, >> I am just relaying pain-points that we encountered in neutron. As I have >> said below it makes the development process a lot quicker for people >> working on external d

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-03-07 Thread Devananda van der Veen
I know I'm arriving late to this thread, but I want to chime in with a resounding "yes!" to this approach. We've held to a fairly strict policy around maintaining compatibility within the driver API since early on, and we'll continue to do that as we add new interfaces (see the new ManagementInter

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-03-02 Thread Anita Kuno
On 02/28/2015 09:36 PM, Ramakrishnan G wrote: >> You may not realize you do a disservice to those reading this post and >> those reviewing future patches if you set unreasonable expectations. > >> Telling others that they can expect a patch merged in the same day is >> not reasonable, even if that

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-03-02 Thread Kyle Mestery
On Sun, Mar 1, 2015 at 4:32 AM, Gary Kotton wrote: > Hi, > I am just relaying pain-points that we encountered in neutron. As I have > said below it makes the development process a lot quicker for people > working on external drivers. I personally believe that it fragments the > community and feel

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-03-02 Thread Dmitry Tantsur
On 02/28/2015 07:28 AM, Ramakrishnan G wrote: Hello All, Hi! This is about adding vendor drivers in Ironic. In Kilo, we have many vendor drivers getting added in Ironic which is a very good thing. But something I noticed is that, most of these reviews have lots of hardware-specific code in

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-03-01 Thread Clint Byrum
Excerpts from Gary Kotton's message of 2015-03-01 02:32:37 -0800: > Hi, > I am just relaying pain-points that we encountered in neutron. As I have > said below it makes the development process a lot quicker for people > working on external drivers. I personally believe that it fragments the > commu

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-03-01 Thread Gary Kotton
Hi, I am just relaying pain-points that we encountered in neutron. As I have said below it makes the development process a lot quicker for people working on external drivers. I personally believe that it fragments the community and feel that the external drivers loose the community contributions an

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-02-28 Thread Ramakrishnan G
> You may not realize you do a disservice to those reading this post and > those reviewing future patches if you set unreasonable expectations. > Telling others that they can expect a patch merged in the same day is > not reasonable, even if that has been your experience. While we do our > best to

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-02-28 Thread Anita Kuno
On 02/28/2015 01:28 AM, Ramakrishnan G wrote: > Hello All, > > This is about adding vendor drivers in Ironic. > > In Kilo, we have many vendor drivers getting added in Ironic which is a > very good thing. But something I noticed is that, most of these reviews > have lots of hardware-specific cod

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-02-28 Thread Clint Byrum
I'm not sure I understand your statement Gary. If Ironic defines what is effectively a plugin API, and the vendor drivers are careful to utilize that API properly, the two sets of code can be released entirely independent of one another. This is how modules work in the kernel, X.org drivers work, a

Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic

2015-02-28 Thread Gary Kotton
Hi, There are pros and cons for what you have mentioned. My concern, and I mentioned them with the neutron driver decomposition, is that we are are loosing the community inputs and contributions. Yes, one can certainly move faster and freer (which is a huge pain point in the community). How are