On Wed, Jul 29, 2015 at 12:40:53PM +0000, Jeremy Stanley wrote: > On 2015-07-29 10:53:38 +0200 (+0200), Yanis Guenane wrote: > > On 07/28/2015 07:13 PM, Andreas Jaeger wrote: > [...] > > > * 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. > > The question comes from experience preforming similar > synchronization proposals for requirements lists, translations, data > file normalization, et cetera. Specifically, if you update the msync > repo and that triggers change proposals for all your module repos, > but then core reviewers don't get around to approving at least some > of those before the next change merges to the msync repo (especially > possible if you approve two msync changes at roughly the same time), > will it properly update the existing but not-yet-merged changes it > previously proposed rather than creating new changes? > > > > * 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. > > Also, does msync know to take advantage of the on-disk cache of git > repositories on our job workers, or does it clone them all over the > network every time it runs? The latter can lead to additional > fragility.
For people playing at home, I've spend the last week working on this. I have a few reviews up that make this work 'the infra way'[1][2]. I had to add new flags into modulesync to do this, but it looks to be working well. Bascially, openstack-infra handles the git functions, msync handles the templating of puppet modules. I've included a link for people to see it in action[3], please ignore the '1git' errors, this was done to stop the script from creating reviews. [1] https://review.openstack.org/210517 [2] https://review.openstack.org/210528 [3] http://paste.openstack.org/show/412611/ > -- > Jeremy Stanley > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
