<div dir="ltr"><div><div><div>Hi,<br><br></div>one of cons: there might be delay in time when we need to apply a patch to upstream project and thus fork some project (needs some time to prepare patch to projects, get reviews and approves, etc). Having said that I vote for "lazy downstreaming".<br><br></div>Regards,<br></div>Alex<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 10:12 AM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a continuation of the forked discussion [0].<br>
<br>
The idea is to relax Fuel-library downstream policy and implement a<br>
"lazy downstreaming", which is to not create a downstream fork of a<br>
puppet module referenced in the librarian Puppetfile unless we have to<br>
do so.<br>
<br>
The relaxed policy would unblock an upstream switching of the rabbitmq<br>
[1] and corosync [2] modules as well.<br>
<br>
Pros:<br>
- Reduced costs of maintaining downstream forks because of the laziness<br>
of the forking process. This much better distributes load to Fuel<br>
engineering and HW resources in time. Even though related tasks may be<br>
one-time, HW resources and network bandwidth shall not be wasted for<br>
keeping and cloning unnecessary forks (unless we have no choice but to<br>
fork things)<br>
-  A module might remain as direct upstream reference in the Puppetfile<br>
for quite a while. This as well shows an amount of the hidden technical<br>
debt in much more clean representation - downstream vs upstream refs in<br>
the Puppetfile.<br>
- Some generic, non OpenStack puppet modules will barely require<br>
backporting of separate patches by older tags as they work just<br>
straightforward and the latest version works for every supported Fuel<br>
release as well. Those would save resources because of the laziness of<br>
the relaxed process will never require to create downstream forks for<br>
such modules!<br>
<br>
Cons:<br>
- I see none. For "unlucky" modules, the *same* amount of work shall be<br>
done anyway, although with the lazy process in place it will be<br>
distributed in time much better.<br>
<br>
[0]<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2016-January/085249.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-January/085249.html</a><br>
[1] <a href="https://review.openstack.org/#/c/271217" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/271217</a><br>
[2] <a href="https://review.openstack.org/#/c/273036/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/273036/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<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>
</font></span></blockquote></div><br></div>