[openstack-dev] [Fuel][library] relax downstream policy for puppet modules managed by librarian

Bogdan Dobrelya bdobrelia at mirantis.com
Fri Jan 29 09:12:58 UTC 2016


This is a continuation of the forked discussion [0].

The idea is to relax Fuel-library downstream policy and implement a
"lazy downstreaming", which is to not create a downstream fork of a
puppet module referenced in the librarian Puppetfile unless we have to
do so.

The relaxed policy would unblock an upstream switching of the rabbitmq
[1] and corosync [2] modules as well.

Pros:
- Reduced costs of maintaining downstream forks because of the laziness
of the forking process. This much better distributes load to Fuel
engineering and HW resources in time. Even though related tasks may be
one-time, HW resources and network bandwidth shall not be wasted for
keeping and cloning unnecessary forks (unless we have no choice but to
fork things)
-  A module might remain as direct upstream reference in the Puppetfile
for quite a while. This as well shows an amount of the hidden technical
debt in much more clean representation - downstream vs upstream refs in
the Puppetfile.
- Some generic, non OpenStack puppet modules will barely require
backporting of separate patches by older tags as they work just
straightforward and the latest version works for every supported Fuel
release as well. Those would save resources because of the laziness of
the relaxed process will never require to create downstream forks for
such modules!

Cons:
- I see none. For "unlucky" modules, the *same* amount of work shall be
done anyway, although with the lazy process in place it will be
distributed in time much better.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2016-January/085249.html
[1] https://review.openstack.org/#/c/271217
[2] https://review.openstack.org/#/c/273036/

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



More information about the OpenStack-dev mailing list