<div dir="ltr"><br>Emilien,<div><br></div><div>Thanks for re-raising this. This is a sore subject on the Fuel's side, and I will sulk in my own shame for not being better here and continue to encourage my colleagues to be better in this regard.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 10, 2015 at 10:45 PM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Before reading this e-mail, please keep in mind:<br>
<br>
* I have a lot of admiration for Fuel and since I'm working on OpenStack<br>
Installers (at eNovance and now Red Hat), Fuel is something I always<br>
consider a good product.<br>
* This e-mail is about Fuel and Puppet, nothing about Mirantis.<br>
* I'm writing on behalf of my thoughts, and not on our group.<br>
* I'm using open mailing-list for open discussion. There is not bad<br>
spirit in this e-mail and I want to have a productive thread.<br>
<br>
I have some concerns I would like to share with you and hopefully find<br>
some solutions together.<br>
<br>
Since I've been working on Puppet OpenStack (2 years now), I see some<br>
situations that happen - according to me - too often:<br>
<br>
* A bug is reported in both Fuel Library and the Puppet module having<br>
trouble. A patch is provided in Fuel Library (your fork of Puppet<br>
OpenStack modules) but not in Puppet upstream module. That means you fix<br>
the bug for Fuel, and not for Puppet OpenStack community. It does not<br>
happen all the time but quite often.<br></blockquote><div><br></div><div>We had started doing this for puppet-openstack and openstack upstreams, there where some projects that pushed back on this so the team was asked to stop cross adding projects. Lets identify if this is desired by the puppet project or otherwise work out a solution. Obviously adding another project to the same bug is the least work for some of us but it may end up with spam from improperly handled bugs, there are easily 20-50 bug modifications a day from the fuel guys so this could become a fire hose if we are not careful.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* A patch is submitted in a Puppet module and quite often does not land<br>
because there is no activity, no tests or is abandonned later because<br>
fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library<br>
though.<br></blockquote><div><br></div><div>I think this, at least in part, due to the nature in the differences in our CI systems, since we don't yet rely on rspec the patches that can land in fuel-library could lack these and the for encourage some one to only propose to fuel. This is wrong and we need to cover the gap here so the patch has an equal cost to propose so we can eventually show that maintenance is lower in upstream.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* RAW copy/paste between upstream modules code and your forks. In term<br>
of Licensing, I'm even not sure you have the right to do that (I'm not a<br>
CLA expert though) but well... in term of authorship and statistics on<br>
code, I'm not sure it's fair. Using submodules with custom patches would<br>
have been great to respect the authors who created the original code and<br>
you could have personalize the manifests.<br></blockquote><div>(Is possible for us to maintain this data through gerrit with out creating more than one patch set?)<br></div><div><br></div><div>I don't think anyone on the fuel teams prefers to do this. While it's unfair, its a technical issue that we are more than open to a better solution for. Also, if you want to feel better about it (maybe) it costs us a lot to maintain the forks as it is (Technically and Socially as you noted).</div><div><br></div><div>When we started fuel, we had initially stared with submodules, and they where a burden to maintain with our tiny team at the time when we had only 50 modules. Now there are 70 in the directory. Some are ours, some our others. With the numerous upstreams, base commits and effective requirement to move fast some times the forks won. Now that we are larger and have more support (people and tools) It would be a great time to step back and evaluate a better solution.</div><div><br></div><div>For the time being, we have the perceived requirement that we are able patch something quickly if the business need arises. So a solution would require this functionality at least until we have the trust and support to do so directly upstream if necessary.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note: you can see that I don't give any example because I'm not here to<br>
blame people or judge anyone.<br>
<br>
So the goal of my e-mail is to open the discussion and have a *real*<br>
collaboration between Fuel team which seems to have a lot of good Puppet<br>
engineers and Puppet OpenStack team.<br>
<br>
We had this kind of discussion at the Summit (in Vancouver and also<br>
Paris, and even before). Now I would like to officialy know if you are<br>
interested or not to be more involved.<br>
I'm also open at any feedback about Puppet OpenStack group and if<br>
something blocks you to contribute more.<br></blockquote><div><br></div><div>We are very much interested, and have been making progress (even if you cant see it) towards becoming a better member in the community here.</div><div><br></div>* We have opened externally visible CI for nearly all component testing and build processes.  Once we get run ci from upstream trunk working you will be able to see everything<div><br></div><div>* There has been work to pull us up to recent revisions of the modules, this is necessary for us to be close enough to even propose relevant patches to upstream with out wasting time to find that it was already fixed, and to eventually switch to a more friendly system.</div><div><br></div><div>* We just got rid of monoithic roles in or composition layer which has prevented our ability to do any module level CI</div><div><br></div><div>* There is an open task to deploy Openstack from trunk/master which means that we would also need to deploy it using similar puppet manifests</div><div><br></div><div>* Similar to the prior, there is an open task to run fuel-library CI for every upstream module commit</div><div><br></div><div>(Yes, I know we have been talking about these two since ATL, we are making progress, the first two where barriers for this)</div><div><br></div><div>* There is another round of manifest syncs in progress which I expect to yield another rush of patches from us. (more about this shortly)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We have the same goals, having Puppet modules better. I think it can be<br>
win/win: you have less diff with upstream and we have more hands in our<br>
module maintenance.<br>
Thank you for reading so far, and I'm looking forward to reading from you.<br>
<br>
Best regards,<br>
--<br>
Emilien Macchi<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><p dir="ltr">--</p>
<p dir="ltr">Andrew Woodward</p>
<p dir="ltr">Mirantis</p>
<p dir="ltr">Fuel Community Ambassador</p>
<p dir="ltr">Ceph Community</p>