On 07/28/2015 07:13 PM, Andreas Jaeger wrote: > On 07/28/2015 03:35 PM, Yanis Guenane wrote: >> In PuppetOpenstack we have a common set of filesthat are shared across >> all our modules. >> We would like to have an easy way to keep those set of >> filessynchronized. >> Based on some discussions on #openstack-infra, infra might also be >> interested by this problematic. >> >> They are (at least) two approaches for that matter : >> >> * The Puppet community have developed a tool specifically for that >> matter called modulesync[1] widely used in the Puppet community. One >> needs to create a repo[2] with a specific layout, and then running msync >> will ensure all files across every modules specified in the >> managed_modules.yml file are synchronized, and if not will create a >> commit to synchronized them. >> >> * The openstack-infra way : Based on my understanding, we would have >> to create a repo much like this one[3] with all the common files in >> there. puppet_update.sh[4] would need to be modified so that in the for >> loop all the common files are copied and then the regular git workflow >> happens. >> >> The advantage I see relying on modulesync is that all the logic is taken >> care of by modulesync, and the logic of the hook itself holds in one >> line[5], making it pretty simple, to follow, understand and eventually >> debug. >> >> A review have been submitted[6] on infra, relying on a >> propose_msync_update.sh script rather than the propose_update.sh script, >> one of the comment was "I suggest to enhance that file (ie. >> jenkins/scripts/propose_update.sh) instead of creating a new syncing >> setup." >> >> As I see it, using msync and propose_update.sh while keeping the pattern >> it has today is incompatible - as they overlap a lot (projects.txt vs. >> managed_modules.yml, the git worflow, etc..) hence I would rather stick >> with the propose_msync_update.sh patch. Using just the bit of modulesync >> for its templating feature and relying on propose_update.sh for the git >> workflow sounds a bit over complicated here. >> >> Though my hope would be havingboth PuppetOpenstack and Infra to rely on >> the same tooling here as it will make it consistent.I'd like to have >> your feedbacks/ideas, on how best to deal with that problematic. >> >> Thank you, >> >> [1] https://github.com/puppet-community/modulesync >> [2] https://github.com/openstack/puppet-modulesync-configs >> [3] https://github.com/pabelanger/puppet-modules-sync >> [4] >> https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/propose_update.sh >> >> [5] >> https://review.openstack.org/gitweb?p=openstack-infra/project-config.git;a=blob;f=jenkins/scripts/propose_msync_update.sh;h=602615f41a6c09741f953e3310bf1512033dde0c;hb=7ff5fa189392709486bc544273a1949ece4da049#l82 >> >> [6] https://review.openstack.org/#/c/189216 > > Yanis, thanks for the explanation. This helps to understand what > you're doing. Still I have some questions. I'll also comment in the > review with some specific comments. > > Will this script do the same what propose_update.sh does, especially: > > * Send a request to gerrit? Yes, msync will automatically send the request to gerrit. > * If there is a proposed change already for a project, reuse that one > instead of creating a new one? I don't have the answer for that I'd have to look. But this should never happen as the goal here is to enforce a process where a change to a shared file can only be done via the modulesync repository. > * Will msync check out the git repositories itself? Yes, msync checks out the repositories listed in managed_modules.yml, loop on them, clone them, apply the templates and submit the review. > > > Andreas
Thank you for answering the mail and the feedbacks on the review, -- Yanis Guenane __________________________________________________________________________ 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
