From: Samuel Lucas Vaz de Mello <samuellucas@datacom.ind.br>
To: Thomas Koch <thomas@koch.ro>
Cc: git@vger.kernel.org
Subject: Re: Use alternate GIT servers to share traffic
Date: Thu, 26 Mar 2009 10:40:19 -0300 [thread overview]
Message-ID: <49CB85C3.20700@datacom.ind.br> (raw)
In-Reply-To: <200903252145.30226.thomas@koch.ro>
Thomas Koch wrote:
> Hi,
>
> we host a public GIT repository on our high availability company
> cluster. Cloning the repo causes a trafic volume of 326 MB. We'd like to
> avoid that much trafic while still leaving the GIT repo where it is.
>
> I could imagine the following conversation between the GIT client and
> server:
>
> Client: Wanna clone!
> Server: You're welcome. Please note, that while I serve the most current
> state, you can get objects much faster from my collegue Server
> CHEAPHOST.
> Client: Thank you. Will take all the objects I can get from CHEAPHOST
> and come back if I should need anything else!
>
> The enduser should not need to specify anything, but only the regular
> git clone EXPENSIVEHOST line.
>
> Your thoughts?
>
I have a scenario here that is (nearly) similar to what you want.
We have two development sites and we let users choose the server that is closer to them.
As all changes to these repositories are made using push, we use post-receive hooks to syncronize.
User can push no any of the servers and the changes will get replicated.
In the EXPENSIVEHOST you add the CHEAPHOST as remote and put a 'git push --mirror cheaphost' in the post-receive hook.
In the CHEAPHOST, you add EXPENSIVEHOST as remote and changes git config to make it put the references in refs/heads/* instead of refs/remotes/expensivehost/*. In the post-receive hook you add a 'git push --all expensivehost'.
Also, you need to ensure that all users can authenticate in both servers (or, in my case, I made the hook use sudo to push the updates using a special user that authenticate using ssh keys).
The drawback ares:
1) User must manually choose the closest server. (maybe some sort of round-robin DNS would do it automatically?)
2) Branch and tag deletion must be done in the EXPENSIVEHOST.
3) EXPENSIVEHOST stores the remote refs from CHEAPHOST in remotes/cheaphost/* and they are pushed back to CHEAPHOST by push --mirror. These references are not used at all, but they can cause some noise in the log message during pushes.
4) If we have two users committing to the same branch exactly at the same time in the different servers, I'm not sure about what will happen :-). As precaution, I added in CHEAPHOST a cron job that does a 'git remote update' in the repo. So, if the servers became inconsistent, it will perform a forced update from EXPENSIVEHOST to CHEAPHOST.
I have the scenario running just for a few days, so there may be some additional corner cases.
HTH,
- Samuel
prev parent reply other threads:[~2009-03-26 13:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 20:45 Use alternate GIT servers to share traffic Thomas Koch
2009-03-25 22:57 ` Johannes Schindelin
2009-03-26 4:30 ` Andrew Wang
2009-03-26 13:40 ` Samuel Lucas Vaz de Mello [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49CB85C3.20700@datacom.ind.br \
--to=samuellucas@datacom.ind.br \
--cc=git@vger.kernel.org \
--cc=thomas@koch.ro \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).