Mailing List Archive

1 2  View All
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, 2005-11-19 at 18:13 -0600, Lance Albertson wrote:
> is the 25-55 minute lag good enough?

It may need to be good enough. Personally I would like to have < 5-7
min. That way when I'm working with a dev, I can keep up to speed with
her/him without having to resort to an overlay and emailing
ebuilds.tar's. A dedicated 'AT/HT' sync box sounds like an acceptable
solution.

--
Lares Moreau <lares.moreau@gmail.com> | LRU: 400755 http://counter.li.org
Gentoo x86 Arch Tester | ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Prefered
Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E
Re: implementation details for GLEP 41 [ In reply to ]
Lares Moreau wrote:
> On Sat, 2005-11-19 at 18:13 -0600, Lance Albertson wrote:
>
>>is the 25-55 minute lag good enough?

> It may need to be good enough. Personally I would like to have < 5-7
> min. That way when I'm working with a dev, I can keep up to speed with
> her/him without having to resort to an overlay and emailing
> ebuilds.tar's. A dedicated 'AT/HT' sync box sounds like an acceptable
> solution.

For now, I don't want to rsync more than every 30 minutes (concerns of
overloading the main cvs server). Pylon has mentioned that the newer
version of cvs has better commit hooks that may allow for more of a live
replication effect, but I don't expect that to happen any time soon. I
will try and come up with a revised version of GLEP 41 and see if
hparker and folks will agree with this new solution.

We will probably still have the blocking script on this server, but will
be at a much higher level. This is just to prevent folks from abusing
the service or giving out their access for other people to use. I really
don't see that happening, but I would prefer to have some kind of
prevention in place for infra's sake. I'll have to think out details on
the authentication scheme for access, but I would assume it would be per
AT and not a shared access account.

Thoughts?

--
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, 2005-11-19 at 19:02 -0600, Lance Albertson wrote:

> For now, I don't want to rsync more than every 30 minutes (concerns of
> overloading the main cvs server). Pylon has mentioned that the newer
> version of cvs has better commit hooks that may allow for more of a live
> replication effect, but I don't expect that to happen any time soon. I
> will try and come up with a revised version of GLEP 41 and see if
> hparker and folks will agree with this new solution.
>
> We will probably still have the blocking script on this server, but will
> be at a much higher level. This is just to prevent folks from abusing
> the service or giving out their access for other people to use. I really
> don't see that happening, but I would prefer to have some kind of
> prevention in place for infra's sake. I'll have to think out details on
> the authentication scheme for access, but I would assume it would be per
> AT and not a shared access account.
>
> Thoughts?

If any user really wanted to get the access that AT/HT's get, and the
AT/HT was so to give them it, there would be different IP addresses from
the same auth 'similaneously'. ie. logs state, IP A, IPB IPA, IPb. this
would indicate a security violation and revocation of privilege for the
AT/HT. Accomplished Via script?
Personally, If I wanted a user to have access to the same tree I had, I
would say A) chill for 12hrs, B) sync to my local mirror, C) post
ebuild.tar for them. I don't believe there is an issue with AT/HT's
disseminating access to users. However I understand the need to be
prepared in case it happens.

25-55min delay may need to be acceptable.

<brainstorming out loud>
Allow (x) access to the dedicated rsync server, not limited by time.
- Allow Devs to change this number if they feel it is necessary
- <5min access when working directly with Dev.
- number reset every (y) days.
(this means new infra, so prolly not)

Per AT Access:
Each AT upload their ssh_pub to the existing infra - use that
for ?secure? rsync auth.
</>

--
Lares Moreau <lares.moreau@gmail.com> | LRU: 400755 http://counter.li.org
Gentoo x86 Arch Tester | ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Prefered
Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E
Re: implementation details for GLEP 41 [ In reply to ]
Kurt Lieber wrote: [Sat Nov 19 2005, 04:42:41PM CST]
> On Sat, Nov 19, 2005 at 05:06:15PM +0000 or thereabouts, Kurt Lieber wrote:
> If the requirement is for r/o CVS access to the same CVS server that the
> pure-blooded developers use (sorry, couldn't resist) then it may require
> upgrades to our existing server and/or purchasing a new server.

What about authenticated viewcvs on the live CVS server instead? Back
when we had a live viewcvs I used to use it all the time for doing
exactly what the ATs want to do now, and I assume that viewcvs puts much
less load on the server than a CVS pull does.

In any event, do we need a new server anyway? We actually do have some
money that could be spent on such things, and the CVS server is really
high on the list of for which I, personally, would be more than willing
to spend it.

-g2boojum-
--
Grant Goodyear
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
Re: implementation details for GLEP 41 [ In reply to ]
Kurt Lieber wrote: [Sat Nov 19 2005, 04:47:37PM CST]
> OK, fine. Devrel does not have an established track record of retiring
> devs who are otherwise inactive.

Just as an aside, I've seen scores (if not more) of devs retired within
the last couple of months, so I think that problem is currently being
fixed.

-g2boojum-
--
Grant Goodyear
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, 2005-11-19 at 22:25 -0600, Grant Goodyear wrote:
> Kurt Lieber wrote: [Sat Nov 19 2005, 04:42:41PM CST]
> > On Sat, Nov 19, 2005 at 05:06:15PM +0000 or thereabouts, Kurt Lieber wrote:
> > If the requirement is for r/o CVS access to the same CVS server that the
> > pure-blooded developers use (sorry, couldn't resist) then it may require
> > upgrades to our existing server and/or purchasing a new server.
>
> What about authenticated viewcvs on the live CVS server instead? Back
> when we had a live viewcvs I used to use it all the time for doing
> exactly what the ATs want to do now, and I assume that viewcvs puts much
> less load on the server than a CVS pull does.
>
> In any event, do we need a new server anyway? We actually do have some
> money that could be spent on such things, and the CVS server is really
> high on the list of for which I, personally, would be more than willing
> to spend it.
>
> -g2boojum-

If we were able to purchase hardware then we might as well make it the
anon cvs/svn server, no keys/auth are needed then and simple aliases
would suffice on toucan maintained by the AT leads.


--
Ned Ludd <solar@gentoo.org>
Gentoo Linux

--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
On Saturday 19 November 2005 08:25 pm, Grant Goodyear wrote:
> In any event, do we need a new server anyway? We actually do have some
> money that could be spent on such things, and the CVS server is really
> high on the list of for which I, personally, would be more than willing
> to spend it.
>
> -g2boojum-

This is a good possibility.. I personally don't use cvs that much but have
heard from quite a few people that it could be faster. And the box that it
is currently on does not have any OOB management.

We've talked about OSL getting a couple of new boxes for Gentoo, one for a new
dev.gentoo.org and one for cvs, but it's looking like just the one for dev
will be a reality. I will be ordering it next week. That said, we can roll
in an order for an additional box and get a good price on it.

The problem in all of this is the money transfer. I'll check on Monday if
there is a possible way to go from Gentoo Paypal to OSL Foundation. We can
whip out a proposal if that works out. (there are other ways of doing it,
yes, but this would be cheapest I know of right now)

-C

--
Corey Shields
Gentoo Linux Infrastructure Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields
--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
Ned Ludd wrote:
> On Sat, 2005-11-19 at 22:25 -0600, Grant Goodyear wrote:
>
>>Kurt Lieber wrote: [Sat Nov 19 2005, 04:42:41PM CST]
>>
>>>On Sat, Nov 19, 2005 at 05:06:15PM +0000 or thereabouts, Kurt Lieber wrote:
>>>If the requirement is for r/o CVS access to the same CVS server that the
>>>pure-blooded developers use (sorry, couldn't resist) then it may require
>>>upgrades to our existing server and/or purchasing a new server.
>>
>>What about authenticated viewcvs on the live CVS server instead? Back
>>when we had a live viewcvs I used to use it all the time for doing
>>exactly what the ATs want to do now, and I assume that viewcvs puts much
>>less load on the server than a CVS pull does.
>>
>>In any event, do we need a new server anyway? We actually do have some
>>money that could be spent on such things, and the CVS server is really
>>high on the list of for which I, personally, would be more than willing
>>to spend it.
>>
>>-g2boojum-
>
>
> If we were able to purchase hardware then we might as well make it the
> anon cvs/svn server, no keys/auth are needed then and simple aliases
> would suffice on toucan maintained by the AT leads.

I currently have hardware for an anon cvs/svn server, just no time to
implement currently. I was hoping to get to this in the next few months
time permitting of course. I do not want anon cvs/svn on our live server
at all. Any implementation of such service will need to be on separate
dedicated boxes. I haven't worked out the details for 'live' data, but
the possibilities are there I believe for part of it.

We already have a viewcvs site that updates every 30 minutes (or maybe
an hour, I don't quite remember) that's in testing currently. Check out
viewcvstest.g.o if you're curious. To me the cvs/svn server should only
be doing that, nothing more. For now, i think the dedicated rsync server
is the best route that will accomplish the needs of the ATs. (which I
have a server for also). Until we get an official anon cvs/svn service
implemented, this is the best infra can do.

--
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net
Re: implementation details for GLEP 41 [ In reply to ]
Corey Shields wrote:
> On Saturday 19 November 2005 08:25 pm, Grant Goodyear wrote:
>
>>In any event, do we need a new server anyway? We actually do have some
>>money that could be spent on such things, and the CVS server is really
>>high on the list of for which I, personally, would be more than willing
>>to spend it.
>>
>>-g2boojum-
>
>
> This is a good possibility.. I personally don't use cvs that much but have
> heard from quite a few people that it could be faster. And the box that it
> is currently on does not have any OOB management.
>
> We've talked about OSL getting a couple of new boxes for Gentoo, one for a new
> dev.gentoo.org and one for cvs, but it's looking like just the one for dev
> will be a reality. I will be ordering it next week. That said, we can roll
> in an order for an additional box and get a good price on it.
>
> The problem in all of this is the money transfer. I'll check on Monday if
> there is a possible way to go from Gentoo Paypal to OSL Foundation. We can
> whip out a proposal if that works out. (there are other ways of doing it,
> yes, but this would be cheapest I know of right now)

Yeah, we defiantly could use a beefy new server for CVS/SVN. Just make
sure you chat with robbat2/Pylon on the specifics for the requirements.
I believe the main thing they wanted was lots of ram.

--
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net
Re: implementation details for GLEP 41 [ In reply to ]
On Saturday 19 November 2005 08:50 pm, Lance Albertson wrote:
> Yeah, we defiantly could use a beefy new server for CVS/SVN. Just make
> sure you chat with robbat2/Pylon on the specifics for the requirements.
> I believe the main thing they wanted was lots of ram.

As discussed before, the new dev will be a dual xeon 3.0/1M, 2GB ram, 6x146GB
U320 scsi. adding more ram to this setup wouldn't be a problem. I'll cc
them and ask how much ram hits the sweet spot and get a new quote this week.

-C

--
Corey Shields
Gentoo Linux Infrastructure Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields
--
gentoo-dev@gentoo.org mailing list
Re: CVS-Server requirements (was: implementation details for GLEP 41) [ In reply to ]
* Lance Albertson <ramereth@gentoo.org> [05/11/19 22:50 -0600]:
> Yeah, we defiantly could use a beefy new server for CVS/SVN. Just make
> sure you chat with robbat2/Pylon on the specifics for the requirements.
> I believe the main thing they wanted was lots of ram.

CVS/SVN doesn't need much CPU load or even several CPUs and
also we don't need a lot of disk-space. But our setup could
make use of a lot of fast RAM and a nice RAID (which we
don't have at the moment).

So specs are:
- ~3GHz Xeon
- 4-6GB of RAM
- RAID-5 or -10 with u320 disks (for the actual data, 20GB
would be enough for the next years)
- a very good network-connection

Regards, Lars

--
Lars Weiler <pylon@gentoo.org> +49-171-1963258
Gentoo Linux PowerPC : Developer and Release Engineer
Gentoo Infrastructure : CVS Administrator
Gentoo Foundation : Trustee
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 09:04:13PM -0800, Corey Shields wrote:
> On Saturday 19 November 2005 08:50 pm, Lance Albertson wrote:
> > Yeah, we defiantly could use a beefy new server for CVS/SVN. Just make
> > sure you chat with robbat2/Pylon on the specifics for the requirements.
> > I believe the main thing they wanted was lots of ram.
> As discussed before, the new dev will be a dual xeon 3.0/1M, 2GB ram, 6x146GB
> U320 scsi. adding more ram to this setup wouldn't be a problem. I'll cc
> them and ask how much ram hits the sweet spot and get a new quote this week.
4Gb of RAM would enable the current CVS speedups to continue, and also
allow for keeping all of the CVS/SVN trees (2Gb of data presently) in
the memory-cached files (important for speed).

The Xeon's need to be be HT-capable (the present ones are), as that
helps spread available CPU around the tasks that do use it better.

The 6x146GB is overkill for storage, unless you have some other plans
that I'm not aware of (I'm assuming RAID5 with a hot-spare, so 4x146GB
usable). 6x72GB might be more suitable for the budget.

--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: CVS-Server requirements (was: implementation details for GLEP 41) [ In reply to ]
The Specs giving were for the new dev box, not the projected CVS/SVN
box. I think the wire got crossed somewhere along the way.
-Lares
On Sun, 2005-11-20 at 06:31 +0100, Lars Weiler wrote:
> * Lance Albertson <ramereth@gentoo.org> [05/11/19 22:50 -0600]:
> > Yeah, we defiantly could use a beefy new server for CVS/SVN. Just make
> > sure you chat with robbat2/Pylon on the specifics for the requirements.
> > I believe the main thing they wanted was lots of ram.
>
> CVS/SVN doesn't need much CPU load or even several CPUs and
> also we don't need a lot of disk-space. But our setup could
> make use of a lot of fast RAM and a nice RAID (which we
> don't have at the moment).
>
> So specs are:
> - ~3GHz Xeon
> - 4-6GB of RAM
> - RAID-5 or -10 with u320 disks (for the actual data, 20GB
> would be enough for the next years)
> - a very good network-connection
>
> Regards, Lars
>
--
Lares Moreau <lares.moreau@gmail.com> | LRU: 400755 http://counter.li.org
Gentoo x86 Arch Tester | ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Prefered
Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E
Re: Re: implementation details for GLEP 41 [ In reply to ]
On Sun, 2005-11-20 at 04:29 -0700, Duncan wrote:
> If the capacity is there, go RAID6 (dual parity RAID5, so two drives can
> drop out without the thing dieing) with a hot-spare as well, so
> threex146GB usable.

Is RAID6 production ready?
--
Lares Moreau <lares.moreau@gmail.com> | LRU: 400755 http://counter.li.org
Gentoo x86 Arch Tester | ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Prefered
Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E
Re: Re: implementation details for GLEP 41 [ In reply to ]
On Sun, 20 Nov 2005 07:49:11 -0700 Lares Moreau
<lares.moreau@gmail.com> wrote:
| On Sun, 2005-11-20 at 04:29 -0700, Duncan wrote:
| > If the capacity is there, go RAID6 (dual parity RAID5, so two
| > drives can drop out without the thing dieing) with a hot-spare as
| > well, so threex146GB usable.
|
| Is RAID6 production ready?

RAID6 was only invented because a certain large hardware manufacturer
shipped a bunch of duff disks in one of its drive arrays. In practice
it's not necessary, because if you're taking the kind of damage that
kills multiple drives over a short period then you're going to lose
more than two drives anyway.

--
Ciaran McCreesh : Gentoo Developer (Look! Shiny things!)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
Re: Re: implementation details for GLEP 41 [ In reply to ]
On Sunday 20 November 2005 06:49 am, Lares Moreau wrote:
> On Sun, 2005-11-20 at 04:29 -0700, Duncan wrote:
> > If the capacity is there, go RAID6 (dual parity RAID5, so two drives can
> > drop out without the thing dieing) with a hot-spare as well, so
> > threex146GB usable.
>
> Is RAID6 production ready?

If you are running HP equipment they have been doing it for years, calling it
RAID ADG (advanced data guarding iirc). I've setup all of my servers as RAID
ADG plus a hot spare to compensate for their disk failure rate.

-C

--
Corey Shields
Gentoo Linux Infrastructure Team
Gentoo Foundation Board of Trustees
http://www.gentoo.org/~cshields
--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
Robin H. Johnson posted
<20051120054441.GA17389@curie-int.vc.shawcable.net>, excerpted below, on
Sat, 19 Nov 2005 21:44:41 -0800:

> The 6x146GB is overkill for storage, unless you have some other plans
> that I'm not aware of (I'm assuming RAID5 with a hot-spare, so 4x146GB
> usable). 6x72GB might be more suitable for the budget.

As I just RAID-ed my main system, and have the info fresh...

If the capacity is there, go RAID6 (dual parity RAID5, so two drives can
drop out without the thing dieing) with a hot-spare as well, so
threex146GB usable.

In any case, I'd go RAID6 with no hot-spare over RAID5 with a hot-spare,
as it's effectively the same thing, only with RAID6, you can lose two at
once without dieing, instead of only one -- and you hope the second waits
to die at least until the hot-spare gets synced.

This of course assumes software RAID, as RAID6 is certainly a kernel
option. If it's hardware RAID, you of course go with the capacities the
hardware supplies, and I'd guess RAID6 is a less common option, certainly
less commonly known.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list
Re: Re: implementation details for GLEP 41 [ In reply to ]
Ciaran McCreesh posted <20051120145749.0027af0d@snowdrop.home>, excerpted
below, on Sun, 20 Nov 2005 14:57:49 +0000:

> On Sun, 20 Nov 2005 07:49:11 -0700 Lares Moreau
> <lares.moreau@gmail.com> wrote:
> | On Sun, 2005-11-20 at 04:29 -0700, Duncan wrote:
> | > If the capacity is there, go RAID6 (dual parity RAID5, so two
> | > drives can drop out without the thing dieing) with a hot-spare as
> | > well, so threex146GB usable.
> |
> | Is RAID6 production ready?
>
> RAID6 was only invented because a certain large hardware manufacturer
> shipped a bunch of duff disks in one of its drive arrays. In practice
> it's not necessary, because if you're taking the kind of damage that
> kills multiple drives over a short period then you're going to lose
> more than two drives anyway.

There's another advantage as well. Single disk failure is common enough
to be worrying about or raid5 wouldn't be in consideration. I'm
certainly no expert, but from from my research previous to installing
here, it is said that raid6 in single failure mode maintains speed,
while a raid5 with hot-spare would be responding far slower during the
same time, as it brought the hot-spare online and did the rebuild.

Thus, if one is going to bother with the hot-spare in the first place,
rather than just run the raid5 in degraded mode until a spare can be
procured and installed, one might as well put that hot-spare to use making
the raid5 a raid6, both protecting against the corner-case of a
short-period compound failure, AND maintaining speed during a simple
failure.

Of course, if that speed maintenance is a a critical factor, then one
would hot-spare the raid6 as well, so non-degraded operation could be
resumed ASAP, thus again allowing a single failure without degrading speed.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list

1 2  View All