Replication with inconsistent names

[Rob Heittman]

Ah, the price of evangelism.  I find myself operating a shared Gerrit for a number of private and public projects.  In one case I want to replicate to an existing, known repository at a URL which isn't exactly congruent to my Gerrit project name.

http://gerrit.foo/bar/baz -> http://public.foo/me/barbaz

I can set up my replication.config using groups such that only the bar/baz project will be replicated and land the exact target I specify.  But, if I don't incorporate ${name} in my replication.config URL,  I'll get Guiced:

2) Error injecting constructor, org.eclipse.jgit.errors.ConfigInvalidException: remote.iucnsis-github.url "g...@github.com:gogoego-gerrit/sis.git" lacks ${name} placeholder in /home/gerrit2/etc/replication.config

I have a few workarounds that do work.  But is this a desirable thing to fix in Gerrit -- so operators could replicate an arbitrary project to an arbitrary target more easily?  If so, any guidance on how to implement it would be most welcome.

- Rob

[Shawn Pearce]

On Tue, Jul 20, 2010 at 14:45, Rob Heittman <rob.he...@solertium.com> wrote:
> Ah, the price of evangelism.  I find myself operating a shared Gerrit for a
> number of private and public projects.  In one case I want to replicate to
> an existing, known repository at a URL which isn't exactly congruent to my
> Gerrit project name.
> http://gerrit.foo/bar/baz -> http://public.foo/me/barbaz

Yea, that is a problem. :-)

> I can set up my replication.config using groups such that only the bar/baz
> project will be replicated and land the exact target I specify.  But, if I
> don't incorporate ${name} in my replication.config URL,  I'll get Guiced:
> 2) Error injecting constructor,
> org.eclipse.jgit.errors.ConfigInvalidException: remote.iucnsis-github.url
> "g...@github.com:gogoego-gerrit/sis.git" lacks ${name} placeholder in
> /home/gerrit2/etc/replication.config

That's jiust because the PushReplication class assumes that a missing
${name} implies you made a mistake in the configuration file, and
aborts on startup. :-) Originally the replication.config just came
about as a way for me to ensure that whatever occurs on
review.source.android.com shows up quickly on android.git.kernel.org.
Because all of the projects are mirrored over, and I didn't want to
setup an entry for every project... the current replication system
came about.

> I have a few workarounds that do work.  But is this a desirable thing to fix
> in Gerrit -- so operators could replicate an arbitrary project to an
> arbitrary target more easily?  If so, any guidance on how to implement it
> would be most welcome.

I agree. The current replication system is too restrictive, we should
be more flexible. Probably the best place to do a per-repository
configuration is in the repository's own config file. Maybe we just
need to have PushReplication class look at each project's config for a
remote section that has some flag saying we should replicate to it,
e.g.:

$ cat /base/project.git

[remote "mirror"]
url = some/where/else
push = +refs/*
gerritReplication = true

If it exists, then store it in a map in the PushConfig keyed by
project name so that later when we get a request to replicate
PushConfig can just look in the map, see we have a custom project
configuration, and execute it. But even if we have a custom project
configuration (or two or three, etc.) we should also still look at the
global configuration in replication.config. The administrator might
be using it to make backups of their server, even if the target isn't
to a world readable location, e.g. it might just be another disk on
the same server.

[Rob Heittman]

I like the idea of this:

 $ cat /base/project.git

 [remote "mirror"]
   url = some/where/else
   push = +refs/*
   gerritReplication = true

as an additive change.  Leave poor replication.config alone; it won't break any existing setups that way, and I already use the feature as you described, for local paranoia replication of everything.

If it exists, then store it in a map in the PushConfig keyed by
project name so that later when we get a request to replicate
PushConfig can just look in the map, see we have a custom project
configuration, and execute it.  But even if we have a custom project
configuration (or two or three, etc.) we should also still look at the
global configuration in replication.config.  The administrator might
be using it to make backups of their server, even if the target isn't
to a world readable location, e.g. it might just be another disk on
the same server.

OK.  Seems not too hard to hack that in.  I'll try to make a guinea pig of the project with the funny names, and share my changeset if I'm successful enough to replace my existing workaround.  (Which involves an intermediate repository, bacon grease, and duct tape...)

Thanks as always for the good advice!

- R

[Nasser Grainawi]

I'll second the gerritReplication option as a huge win. This would/could
really smooth out how we currently handle a few release tasks.

Nasser

>
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en