<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 1, 2015 at 4:32 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
I am just relaying pain-points that we encountered in neutron. As I have<br>
said below it makes the development process a lot quicker for people<br>
working on external drivers. I personally believe that it fragments the<br>
community and feel that the external drivers loose the community<br>
contributions and inputs.<br>
Thanks<br>
Gary<br>
<div><div class="h5"><br></div></div></blockquote><div>I find it unfair to say that the decomposition in Neutron caused fragmentation. As of Kilo-2, we had 48 drivers/plugins in-tree in Neutron, with another 10 or so proposed for Kilo. It's not scalable to continue down that path! Further, most of those drivers/plugins were upstream but the contributors were not really contributing to Neutron outside of their own plugins/drivers. The decomposition lets them contribute and merge where they are already contributing: In their own plugins/drivers. It also removes a lot of code from Neutron which most core reviewers could never test or run due to lacking proprietary hardware or software. All of these reasons were in the decomposition spec [1].<br><br></div><div>I've not heard from anyone else who thinks the decomposition is a bad idea or is not going well in practice. The opposite has actually been true: Everyone has been happy with it's execution and the results it's allowing. I credit Armando for his great work leading this effort. It's been a huge effort but the results have been pretty amazing.<br><br></div><div>Thanks,<br></div><div>Kyle<br></div><div> <br>[1] <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">
On 2/28/15, 7:58 PM, "Clint Byrum" <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
<br>
>I'm not sure I understand your statement Gary. If Ironic defines<br>
>what is effectively a plugin API, and the vendor drivers are careful<br>
>to utilize that API properly, the two sets of code can be released<br>
>entirely independent of one another. This is how modules work in the<br>
>kernel, X.org drivers work, and etc. etc. Of course, vendors could be<br>
>irresponsible and break compatibility with older releases of Ironic,<br>
>but that is not in their best interest, so I don't see why anybody would<br>
>need to tightly couple.<br>
><br>
>As far as where generic code goes, that seems obvious: it all has to go<br>
>into Ironic and be hidden behind the plugin API.<br>
><br>
>Excerpts from Gary Kotton's message of 2015-02-28 09:28:55 -0800:<br>
>> Hi,<br>
>> There are pros and cons for what you have mentioned. My concern, and I<br>
>>mentioned them with the neutron driver decomposition, is that we are are<br>
>>loosing the community inputs and contributions. Yes, one can certainly<br>
>>move faster and freer (which is a huge pain point in the community). How<br>
>>are generic code changes percolated to your repo? Do you have an<br>
>>automatic CI that detects this? Please note that when itonic release you<br>
>>will need to release your repo so that the relationship is 1:1...<br>
>> Thanks<br>
>> Gary<br>
>><br>
>> From: Ramakrishnan G<br>
>><<a href="mailto:rameshg87.openstack@gmail.com">rameshg87.openstack@gmail.com</a><mailto:<a href="mailto:rameshg87.openstack@gmail.com">rameshg87.openstack@gmail.com</a>>><br>
>> Reply-To: OpenStack List<br>
>><<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.o">openstack-dev@lists.openstack.o</a><br>
>>rg>><br>
>> Date: Saturday, February 28, 2015 at 8:28 AM<br>
>> To: OpenStack List<br>
>><<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.o">openstack-dev@lists.openstack.o</a><br>
>>rg>><br>
>> Subject: [openstack-dev] [Ironic] Adding vendor drivers in Ironic<br>
>><br>
>><br>
>> Hello All,<br>
>><br>
>> This is about adding vendor drivers in Ironic.<br>
>><br>
>> In Kilo, we have many vendor drivers getting added in Ironic which is a<br>
>>very good thing. But something I noticed is that, most of these reviews<br>
>>have lots of hardware-specific code in them. This is something most of<br>
>>the other Ironic folks cannot understand unless they go and read the<br>
>>hardware manuals of the vendor hardware about what is being done.<br>
>>Otherwise we just need to blindly mark the file as reviewed.<br>
>><br>
>> Now let me pitch in with our story about this. We added a vendor<br>
>>driver for HP Proliant hardware (the *ilo drivers in Ironic). Initially<br>
>>we proposed this same thing in Ironic that we will add all the hardware<br>
>>specific code in Ironic itself under the directory drivers/modules/ilo.<br>
>>But few of the Ironic folks didn't agree on this (Devananda especially<br>
>>who is from my company :)). So we created a new module proliantutils,<br>
>>hosted in our own github and recently moved it to stackforge. We gave a<br>
>>limited set of APIs for Ironic to use - like get_host_power_status(),<br>
>>set_host_power(), get_one_time_boot(), set_one_time_boot(), etc. (Entire<br>
>>list is here<br>
</div></div>>><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforg" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforg</a><br>
>>e_proliantutils_blob_master_proliantutils_ilo_operations.py&d=AwICAg&c=Sq<br>
>>cl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9<br>
>>N3-diTlNj4GyNc&m=QRyrevJwoHB6GFxiTDorDRShZ79rnf-SwtdVwGiYfcc&s=e9_q3eOLqT<br>
>>eI3oNwT_0fur3qzpFLUy9wxVPEjujfAMs&e=<br>
>><<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor</a><br>
>>ge_proliantutils_blob_master_proliantutils_ilo_operations.py&d=AwMFaQ&c=S<br>
>>qcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq<br>
>>9N3-diTlNj4GyNc&m=m5_FxZnmz3<br>
<span class="">> cyIvavSV<br>
><br>
>DImH6xLR79L-svbcYKkjdcnb8&s=fjlOB2ORYcne-cyYnZJO8bdpi4J8rbfCAbmciPllmFI&e=<br>
>>).<br>
>><br>
>> We have only seen benefits in doing it. Let me bring in some examples:<br>
>><br>
>> 1) We tried to add support for some lower version of servers. We could<br>
>>do this without making any changes in Ironic (Review in proliantutils<br>
>><a href="https://review.openstack.org/#/c/153945/" target="_blank">https://review.openstack.org/#/c/153945/</a>)<br>
>> 2) We are adding support for newer models of servers (earlier we use to<br>
>>talk to servers in protocol called RIBCL, newer servers we will use a<br>
>>protocol called RIS) - We could do this with just 14 lines of actual<br>
>>code change in Ironic (this was needed mainly because we didn't think we<br>
>>will have to use a new protocol itself when we started) -<br>
>><a href="https://review.openstack.org/#/c/154403/" target="_blank">https://review.openstack.org/#/c/154403/</a><br>
>><br>
>> Now talking about the advantages of putting hardware-specific code in<br>
>>Ironic:<br>
>><br>
>> 1) It's reviewed by Openstack community and tested:<br>
>> No. I doubt if I throw in 600 lines of new iLO specific code that is<br>
>>here<br>
</span>>>(<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor</a><br>
>>ge_proliantutils_blob_master_proliantutils_ilo_ris.py&d=AwICAg&c=Sqcl0Ez6<br>
>>M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diT<br>
>>lNj4GyNc&m=QRyrevJwoHB6GFxiTDorDRShZ79rnf-SwtdVwGiYfcc&s=tEA3ZOH2Gu6GxHBG<br>
>>PfPB0x9LeHuMcYAcDbqbQyPVHZA&e=<br>
>><<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor</a><br>
>>ge_proliantutils_blob_master_proliantutils_ilo_ris.py&d=AwMFaQ&c=Sqcl0Ez6<br>
>>M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diT<br>
>>lNj4GyNc&m=m5_FxZnmz3cyIvavSVDImH6xLR79L-svbcYKkjdcnb8&s=vYNQ8MopljQOqje3<br>
<div class=""><div class="h5">>>T_aIhtw0oZPK4tFHGnlcbBH6wac&e=>) for Ironic folks, they will hardly take<br>
>>a look at it. And regarding testing, it's not tested in the gate unless<br>
>>we have a 3rd party CI for it. [We (iLO drivers) also don't have 3rd<br>
>>party CI right now, but we are working on it.]<br>
>><br>
>> 2) Everything gets packaged into distributions automatically:<br>
>> Now the hardware-specific code that we add in Ironic under<br>
>>drivers/modules/<vendor>/ will get packaged into distributions, but this<br>
>>code in turn will have dependencies which needs to be installed<br>
>>manually by the operator (I assume vendor specific dependencies are not<br>
>>considered by Linux distributions while packaging Openstack Ironic).<br>
>>Anyone installing Ironic and wanting to manage my company's servers will<br>
>>again need to install these dependencies manually. Why not install the<br>
>>wrapper if there is one too.<br>
>><br>
>> I assume we only get these advantages by moving all of<br>
>>hardware-specific code to a wrapper module in stackforge and just<br>
>>exposing some APIs for Ironic to use:<br>
>> * Ironic code would be much cleaner and easier to maintain<br>
>> * Any changes related to your hardware - support for newer hardware,<br>
>>bug fixes in particular models of hardware, would be very easy. You<br>
>>don't need to change Ironic code for that. You could just fix the bug in<br>
>>your module, release a new version and ask your users to install a newer<br>
>>version of the module.<br>
>> * python-fooclient could be used outside Ironic to easily manage foo<br>
>>servers.<br>
>> * Openstack CI for free if you are in stackforge - unit tests, flake<br>
>>tests, doc generation, merge, pypi release everything handled<br>
>>automatically.<br>
>><br>
>> I don't see any disadvantages.<br>
>><br>
>> Now regarding the time taken to do this, if you have all the code ready<br>
>>now in Ironic (which assume you will already have), perhaps it will take<br>
>>a day to do this - half a day for putting into a separate module in<br>
>>python/github and half a day for stackforge. The request to add<br>
>>stackforge should get approved in the same day (if everything is<br>
>>all-right).<br>
>><br>
>> Let me know all of your thoughts on this. If we agree, I feel we<br>
>>should have some documentation on it in our Ironic docs directory.<br>
>><br>
>> Thanks for reading :)<br>
>><br>
>> Regards,<br>
>> Ramesh<br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>