Open Stack

On Wed, Jul 29, 2015 at 5:40 AM, Jeremy Stanley <fungi at yuggoth.org> 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?
>
No, it would create a new set of changes that for the entire the current
state of the modulesync-configs repository (not just the latest change), so
any unmerged changes from the last sync would have to be manually
abandoned, or the new changes would have to be manually rebased on the old
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.
>
It can take any URI as a remote, so it can clone from the local filesystem
if we tell it to.

> --
> Jeremy Stanley


Modulesync is a beta tool that is in danger of being massively rewritten[1]
and has the potential to allow you to shoot yourself in the foot[2].
Multiple people have suggested that it over-reaches its primary function by
trying to do too many things. Its main value-add is the ability to template
files that are /slightly/ different between repositories. I suspect that
this is something we don't need, so if there is already synchronization
tooling in place in the OpenStack world it makes sense to use that.

Colleen

[1] https://github.com/puppet-community/modulesync/pull/52
[2]
http://lists.openstack.org/pipermail/openstack-infra/2015-July/002965.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150730/4b8847b1/attachment.html>