Open Stack

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, and etc. etc. Of course, vendors could be
irresponsible and break compatibility with older releases of Ironic,
but that is not in their best interest, so I don't see why anybody would
need to tightly couple.

As far as where generic code goes, that seems obvious: it all has to go
into Ironic and be hidden behind the plugin API.

Excerpts from Gary Kotton's message of 2015-02-28 09:28:55 -0800:
> 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 generic code changes percolated to your repo? Do you have an automatic CI that detects this? Please note that when itonic release you will need to release your repo so that the relationship is 1:1...
> Thanks
> Gary
> 
> From: Ramakrishnan G <rameshg87.openstack at gmail.com<mailto:rameshg87.openstack at gmail.com>>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
> Date: Saturday, February 28, 2015 at 8:28 AM
> To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
> Subject: [openstack-dev] [Ironic] Adding vendor drivers in Ironic
> 
> 
> 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 code in them.  This is something most of the other Ironic folks cannot understand unless they go and read the hardware manuals of the vendor hardware about what is being done.  Otherwise we just need to blindly mark the file as reviewed.
> 
> Now let me pitch in with our story about this.  We added a vendor driver for HP Proliant hardware (the *ilo drivers in Ironic).  Initially we proposed this same thing in Ironic that we will add all the hardware specific code in Ironic itself under the directory drivers/modules/ilo.  But few of the Ironic folks didn't agree on this (Devananda especially who is from my company :)). So we created a new module proliantutils, hosted in our own github and recently moved it to stackforge.  We gave a limited set of APIs for Ironic to use - like get_host_power_status(), set_host_power(), get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_operations.py&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=m5_FxZnmz3cyIvavSV
 DImH6xLR79L-svbcYKkjdcnb8&s=fjlOB2ORYcne-cyYnZJO8bdpi4J8rbfCAbmciPllmFI&e=>).
> 
> We have only seen benefits in doing it.  Let me bring in some examples:
> 
> 1) We tried to add support for some lower version of servers.  We could do this without making any changes in Ironic (Review in proliantutils https://review.openstack.org/#/c/153945/)
> 2) We are adding support for newer models of servers (earlier we use to talk to servers in protocol called RIBCL, newer servers we will use a protocol called RIS) - We could do this with just 14 lines of actual code change in Ironic (this was needed mainly because we didn't think we will have to use a new protocol itself when we started) - https://review.openstack.org/#/c/154403/
> 
> Now talking about the advantages of putting hardware-specific code in Ironic:
> 
> 1) It's reviewed by Openstack community and tested:
> No. I doubt if I throw in 600 lines of new iLO specific code that is here (https://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_ris.py&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=m5_FxZnmz3cyIvavSVDImH6xLR79L-svbcYKkjdcnb8&s=vYNQ8MopljQOqje3T_aIhtw0oZPK4tFHGnlcbBH6wac&e=>) for Ironic folks, they will hardly take a look at it.  And regarding testing, it's not tested in the gate unless we have a 3rd party CI for it.  [We (iLO drivers) also don't have 3rd party CI right now, but we are working on it.]
> 
> 2) Everything gets packaged into distributions automatically:
> Now the hardware-specific code that we add in Ironic under drivers/modules/<vendor>/ will get packaged into distributions, but this code in turn will have dependencies  which needs to be installed manually by the operator (I assume vendor specific dependencies are not considered by Linux distributions while packaging Openstack Ironic). Anyone installing Ironic and wanting to manage my company's servers will again need to install these dependencies manually.  Why not install the wrapper if there is one too.
> 
> I assume we only get these advantages by moving all of hardware-specific code to a wrapper module in stackforge and just exposing some APIs for Ironic to use:
> * Ironic code would be much cleaner and easier to maintain
> * Any changes related to your hardware - support for newer hardware, bug fixes in particular models of hardware, would be very easy. You don't need to change Ironic code for that. You could just fix the bug in your module, release a new version and ask your users to install a newer version of the module.
> * python-fooclient could be used outside Ironic to easily manage foo servers.
> * Openstack CI for free if you are in stackforge - unit tests, flake tests, doc generation, merge, pypi release everything handled automatically.
> 
> I don't see any disadvantages.
> 
> Now regarding the time taken to do this, if you have all the code ready now in Ironic (which assume you will already have), perhaps it will take a day to do this - half a day for putting into a separate module in python/github and half a day for stackforge. The request to add stackforge should get approved in the same day (if everything is all-right).
> 
> Let me know all of your thoughts on this.  If we agree, I feel we should have some documentation on it in our Ironic docs directory.
> 
> Thanks for reading :)
> 
> Regards,
> Ramesh