On 16 Aug 2012, at 09:33, Aaron Digulla wrote:
>> So I've cleaned out some cruft, but I think it's likely to recur. The
>> performance of the virtual disk is horribly slow and although the nexus jobs
>> are set up to purge the trash and remove unused items, I think that there's
>> a number of people hitting http://maven.eclipse.org for non-eclipse content.
>
> Why does nexus mirror half of maven central? And why are there *two* repos
> (repo1 and repo2)?
Presumably because the build infra uses half of Maven central, or (more likely)
random developers over the planet put 'maven.eclipse.org' at the front of their
resolution profile and so we are acting as a cache for everything.
So Point 1 to learn; we need to have an internal Nexus instance which is for
the purposes of the internal Hudson infra caching, and we need to have an
external one that can contain published Eclipse content. Ideally members of the
public should only be able to see the latter.
Point 2 to learn; the two repo1/repo2 were created to do some kind of load
balance/mirror between the two (it was also created shortly after the repo1 DNS
entry went wobbly a couple of years back). In retrospect we should have a
single 'central' repo and then use the 'mirror' in the repository proxy
configuration to utilise either of these. That would save storing a bunch of
stuff twice. (In fact, we seem to be storing a third copy under 'central' which
is the group, which doesn't help.)
Point 3 to learn is that disk space needs to be monitored and alerted, in a way
(presumably) similar to the Hudson setup. Part time admins rarely work out well.
Point 4 is that whilst processing power for a VM isn't an issue, great gobs of
virtual disk are a serious bottleneck to doing most of the work. Even a du -s *
in the repositories folder takes significant amounts of time (tens of minutes)
which really doesn't help when you are trying to solve the problems caused by
lack of disk space.
Point 5 is that really, published Eclipse content should migrate to Maven
Central instead of being hosted on Eclipse infra. The key challenge, it seems,
is getting it in a suitable form. I believe that CBI may be the way to make
this happen.
Alex
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
