> There should be an order. Try the first one...if fail try the second... > his idea is here: http://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=33 > What do you suggest? > > I've set up another server at NCSU dedicated (ideally) to installs and > updates for the RK at NCSU. It is locked down so only NCSU can get to > it rather than have to fight with the folks on kickstart, and the fact > that kickstart tends to fall over 2 - 3 times a year. I'd like to get > some redundancy so if updates.linux.ncsu.edu fails yum will try > kickstart. guess I'm just debating whether or not redundancy belongs in the client or in the infrastructure or maybe both. I need to clean up some of these functions some more. A lot of new, little things have been creeping into the code and I want to make sure I have a handle on all of them before they make things ugly and unmaintainable. So I'm taking my time evaluating where they will effect the code. That's why I was asking - is this the best place to provide the redundancy? On some level I think the client is a good place b/c the client is the place where the failure's symptoms are noticed the most. On another level this is a fault of bad infrastructure in the network and should yum be correcting for that here? give me a little more time to sift out some of the other changes and I'll work on this one. I'd like to suggest that the yum source is not overly complex nor terribly long. If someone wants to work on this and send patches I'd be interested to see what they have. I'd suggest making sure your patches work against cvs and I'd generally recommend people look at doing new work on the rpm_4_2 branch not HEAD -sv
