Open Stack

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