 |
 |
All, I'm sorry for the awkward title, but I thought it would be better to start a new topic on this because the other thread got shredded with side-issues. There may be a problem with the planning that we have to move out of the way before we can use the new software. Part 1 - Recap on original gLite 3.2 thread -------------------------------------------------------- In the original thread, we pronounced these things: * gLite 3.1 goes before 1 Oct (JH) * There will be no exceptions ! (LC) * gLite 3.2 should go before 1 Oct; must go before 1 Nov, with exceptions for 3.2 WN (LC) * Reason: EMI-1 WN has problems (LC) * But EMI-2 also has no usable WN, and more testing to be discussed (JC) * Aside: arguably pointless to go from working gLite 3.1 to working gLite 3.2, as 3.2 will go soon; yet there is no EMI 1 or 2 WN to go to. Therefore, stick on 3.1?? * Anyway, gLite 3.2 WN may be extended to the end of 2012 because of all this (LC) Part 2 - Potential Problem with this plan ------------------------------------------------------ I have tried an EMI Torque (version 2.5.7-7) with the gLite 3.2 WN (2.3.6-2), and it won't work. Someone else should verify this independently, but I am quite convinced that it is incompatible. When I tried to get jobs to run, this error came out: 08/13/2012 14:36:01;0080;PBS_Server;Req;req_reject;Reject reply code=15043(Execution server rejected request MSG=cannot send job to mom, state=PRERUN), aux=0, type=RunJob, from [log in to unmask] The "Cluster Resources" documentation on the problem was unhelpful, but from what I can see of it, it means PBSE_STAGEIN; i.e. the torque server couldn't even get its stagein files on the WN client. To get it to work, I had to kludge the old gLite 3.2 WN client with new RPMs for TORQUE 2.5.7-7, and get a proper MUNGE key on the WN system. After that, things kicked in and it worked OK. Part 3 - Implications -------------------------- If it is true that gLite 3.2 WN can't work with EMI torque, then it is pointless to extend security support only for WN - the whole stack would need special dispensation. It would be good if someone can independently verify this. Maybe I missed a trick somewhere in the validation. If not, then we're going to have to come up with a better plan for our upgrades. Cheers, Steve -- Steve Jones [log in to unmask] System Administrator office: 220 High Energy Physics Division tel (int): 42334 Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2334 University of Liverpool http://www.liv.ac.uk/physics/hep/