From: Raymond Jennings <shentino@gmail.com>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] RFC: Dropping rsync as a tree distribution method
Date: Tue, 18 Dec 2018 10:38:50 -0800 [thread overview]
Message-ID: <CAGDaZ_odTJH+ON+B0sw5pSYCmeZAARjYs_51EJ4VOpxydadxFQ@mail.gmail.com> (raw)
In-Reply-To: <CAAr7Pr-NA6sTTSRJP4Mzja+FLtN0DPc40DkdSmfoHuFro6sOfw@mail.gmail.com>
What if as a first step, rsync was only dropped as the default?
If you change the default from rsync to git, you'd be closer to
removing rsync, but it's not as drastic as a sudden removal. Would
give time to make sure it works properly without the risk of breaking
everything.
On Tue, Dec 18, 2018 at 10:37 AM Alec Warner <antarus@gentoo.org> wrote:
>
>
>
> On Tue, Dec 18, 2018 at 1:15 PM Brian Evans <grknight@gentoo.org> wrote:
>>
>> On 12/15/2018 11:15 PM, Alec Warner wrote:
>> > Hi,
>> >
>> > I am currently embarking on a plan to redo our existing rsync[0] mirror
>> > network. The current network has aged a bit. Its likely too large and is
>> > under-maintained. I think in the ideal case we would instead pivot this
>> > project to scaling out our git mirror capabilities and slowly migrate
>> > all consumers to pulling the git tree directly. To that end, I'm looking
>> > for blockers as to why various customers cannot switch to pulling the
>> > gentoo ebuild repository from git[1] instead of rsync.
>> >
>> > So for example:
>> >
>> > - bandwidth concerns (preferably with documentation / data.)
>> > - Firewall concerns
>> > - CPU concerns (e.g. rsync is great for tiny systems?)
>> > - Disk usage for git vs rsync
>> > - Other things i have not thought of.
>> >
>> > -A
>> >
>> > [0] This excludes emerge-webrsync; which I don't plan on touching.
>> > [1] Rich talked about some downsides earlier
>> > at https://lwn.net/Articles/759539/; but while these are challenges
>> > (some fixable) they are not necessarily blockers.
>>
>> I personally would be sad to see rsync go as I use the git developer
>> tree as my main repository on 2 machines. This is so I can develop and
>> update from the single source. These have no news or md5-cache and it
>> can be painful to generate metadata on one of them.
>
>
> So my strawperson response is that you should have 2 repos.
>
> PORTDIR=https://gitweb.gentoo.org/repo/sync/gentoo.git/log/?h=master # a local copy of this thing.
> PORTDIR_OVERLAY=/path/to/your/checkout/of/gentoo.git
>
> I suspect however that this likely performs ...poorly, particularly in worst case situations as the 'overlay' would of course be massive in this configuration.
>
>>
>>
>> I rely on scripts to pull down the rsync metadata to expedite this
>> process. eg. rsync <host>/gentoo-portage/metadata/md5-cache/. Git has
>> no easy sub-tree download equivalent that I know of.
>
>
> So I think overlaying the news and GSLA bits are easy (you have a post-sync script that cd's into various directories and clones the news and GSLA repos.) The costly bit is likely the metadata regeneration for your development branch of the tree. I'd be curious to see how much this costs (both cold and hot) for you to generate locally.
>
> -A
>
>>
>>
>> Brian
>>
next prev parent reply other threads:[~2018-12-18 18:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-16 4:15 [gentoo-project] RFC: Dropping rsync as a tree distribution method Alec Warner
2018-12-16 4:40 ` Matt Turner
2018-12-16 5:13 ` Georgy Yakovlev
2018-12-16 5:17 ` Alec Warner
2018-12-16 6:50 ` Raymond Jennings
2018-12-16 6:52 ` Raymond Jennings
2018-12-16 7:38 ` Zac Medico
2018-12-16 7:42 ` Zac Medico
2018-12-18 17:28 ` Andrew Savchenko
2018-12-16 6:55 ` Raymond Jennings
2018-12-16 10:22 ` Toralf Förster
2018-12-17 17:26 ` Matt Turner
2018-12-17 17:43 ` Raymond Jennings
2018-12-18 3:57 ` Georgy Yakovlev
2018-12-18 4:02 ` Raymond Jennings
2018-12-18 8:06 ` Robin H. Johnson
2018-12-20 1:18 ` Kent Fredric
2018-12-16 11:34 ` Rich Freeman
2018-12-16 21:10 ` Matthew Thode
2018-12-20 1:26 ` Kent Fredric
2018-12-16 17:15 ` Toralf Förster
2018-12-16 17:38 ` M. J. Everitt
2018-12-16 18:05 ` M. J. Everitt
2018-12-16 18:36 ` Rich Freeman
2018-12-16 18:41 ` M. J. Everitt
2018-12-18 9:55 ` Andrew Savchenko
2018-12-18 11:36 ` Raymond Jennings
2018-12-18 17:14 ` Andrew Savchenko
2018-12-18 18:00 ` Alec Warner
2018-12-18 22:13 ` M. J. Everitt
2018-12-18 11:55 ` Michał Górny
2018-12-20 1:43 ` Kent Fredric
2018-12-20 2:33 ` Rich Freeman
2018-12-20 16:21 ` Kent Fredric
2018-12-18 18:14 ` Brian Evans
2018-12-18 18:37 ` Alec Warner
2018-12-18 18:38 ` Raymond Jennings [this message]
2018-12-18 20:29 ` Alec Warner
2018-12-18 18:42 ` Rich Freeman
2018-12-19 23:46 ` Robin H. Johnson
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=CAGDaZ_odTJH+ON+B0sw5pSYCmeZAARjYs_51EJ4VOpxydadxFQ@mail.gmail.com \
--to=shentino@gmail.com \
--cc=gentoo-project@lists.gentoo.org \
/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