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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
