Hi
To answer Jeremy's question:
We are keen to move at RAL although there is no pressure on us to move.
I have asked for this years CPU procurement at RAL to be installed with SL6 on them. They are a few weeks away from going into production. There is a gridSL6 queue we are testing (for ATLAS and CMS currently, it only has 4 old WN in it) but when the new machines are ready we will add them to that and other VOs will be welcome to test. I am hopeful that we will discover that the VOs software can run on both SL5 and 6 and that we won't need to have separate queues, beyond this testing phase and we can just do a gradual roll out.
Obviously if it all goes wrong, we can just put SL5 back on the new machines in order to hit our pledge in April.
Alastair
On 7 Feb 2013, at 15:51, Jeremy Coles wrote:
> An actual transition strategy and timeline is definitely tied up with the experiment needs and porting progress. I'm keen though to hear if there are any sites other than ECDF where a move sooner rather than later (or later rather than sooner!) is preferred. This is really intended to be sure that if asked I can explain the UK _sites_ position.
>
> Thanks,
> Jeremy
>
>
>
> On 7 Feb 2013, at 15:38, Alessandra Forti wrote:
>
>> It depends on the experiment. CMS has different executables and needs at the very least separate queues. Atlas uses compatibility libraries and can run SL5 releases on SL6 so it is a bit smoother but they are not ready to go on a big scale. Lhcb are like CMS I think.
>>
>> All experiments agreed that we can talk again after Moriond.
>>
>> cheers
>> alessandra
>>
>>
>> On 07/02/2013 15:27, Stephen Jones wrote:
>>> On 02/07/2013 03:05 PM, Jeremy Coles wrote:
>>>> Dear All,
>>>>
>>>> I would like to understand whether any GridPP sites have a strong need to move their WNs to SL6 and what would the sysadmins on this list consider as a reasonable timeline on which to migrate their WNs to SL6?
>>>>
>>>
>>> Hi Jeremy,
>>>
>>> We (Liv) don't "need" to move yet. There are some technical issues
>>> surrounding the migration, and we might need to do a bit of
>>> research.
>>>
>>> Can a cluster be mixed sl5 and sl6 and run the same jobs, i.e.
>>> is it a big bang or an incremental migration?
>>>
>>> If it's an incremental migration, we can put (say) 4 x WNs on SL6
>>> and see how it goes. It's dead easy, and no risk.
>>>
>>> But if it's a big bang migration, we need more coordination.
>>> If we want to be able to rollback, we will need separation, via
>>> some scheme (spare CEs, two batch head nodes, two queues,
>>> scheduling rules or whatever). We'd make the transition to
>>> the new SL6 setup, and gradually retire one set while bringing the
>>> other on line. But this will need some careful thinking through
>>> to dodge the constraints!
>>>
>>> Does anyone already have a good plan in their back pocket? Can I see
>>> it, please?
>>>
>>> Steve
>>>
>>>
>>>> Many thanks,
>>>> Jeremy
>>>
>>>
>>
>>
>> --
>> Facts aren't facts if they come from the wrong people. (Paul Krugman)
|