> some site want/have to go ahead some discount has to be worked out

I was referring to SSC here.

cheers
alessandra
>
> cheers
> alessandra
>
> On 14/07/2011 11:39, J Coles wrote:
>> Hi Alessandra
>>
>> Glad to hear that Manchester is taking in the bigger picture with 
>> regards to performance and stability. I suspect everyone is to some 
>> extent and my email was just to state my concern explicitly.
>>
>> We run a production service and the accounting period is an arbitrary 
>> slice of that so I can not agree that it is a good strategy (to our 
>> end users) to push interventions to one or other ends of that slice. 
>> There are times when we would want to discourage uncertain 
>> interventions and these are when demand peaks such as around 
>> conferences. One reason for suggesting upgrades before the start of 
>> the current accounting period was that it acted as a target date for 
>> getting things done in a year when we expect utilisation to steadily 
>> rise and interventions to have bigger impacts - I would be surprised 
>> if anyone actually said to postpone work.
>>
>> An interesting related topic in this area was raised at the WLCG 
>> workshop and related to the move from SL5 to SL6 vs SL7 since 
>> EMI-1/UMD-1 is only available on SL5 and a slightly provocative 
>> proposal from Markus was that it may be better to have EMI/UMD work 
>> to an SL7 release rather than a short lived SL6 one.
>>
>> Hi Simon
>>
>> To my knowledge there is no concerted joined up thinking with these 
>> announcements for Tier-2s. At the monthly Tier-1 coordination 
>> meetings the experiments provide direct feedback on the proposals for 
>> Tier-1s and at the daily meetings there is some negotiation onTier-1 
>> specific interventions; it would not be possible to do this for 
>> Tier-2s across WCG but it likely happens at some level within the UK 
>> experiment meetings. I'll need to look into where the baseline 
>> recommendations are now being driven from to understand the 
>> connection with experiment Tier-2 demands better and how we can get 
>> more involved.
>>
>>> Maybe in the UK we should just coordinate staggered site downtimes 
>>> if they are required so the impact on the WLCG is no more than one 
>>> site at a time?
>> I think this is what we concluded previously but in practice it is 
>> not (as far as I am aware) being coordinated except perhaps as a 
>> by-product of the storage group discussions. This is going to be 
>> increasingly important  as resources get stretched later this year 
>> and the experiments push more critical tasks onto larger Tier-2s. It 
>> will not always be possible to coordinate as some downtimes are 
>> caused by things wider than the grid site, but with middleware 
>> upgrades it is definitely something that we need to look at again.
>>
>> Jeremy
>>
>>
>>
>> On 14 Jul 2011, at 11:00, Alessandra Forti wrote:
>>
>>> Hi Jeremy,
>>>
>>> The PMB itself said to do all potentially disruptive upgrades before 
>>> or after. Personally I haven't stopped doing things major 
>>> interventions since the beginning of May have been reconfiguring the 
>>> storage data servers network, dpm head node database tuning applied 
>>> to all mysql servers and installing cvmfs moving the whole atlas and 
>>> lhcb on it. I deemed this changes necessary for the stability and 
>>> performance of the site.
>>>
>>> I do not deem upgrading to 1.8.0 such an advantage to risk it 
>>> especially in accounting period. Not to count that it requires a 
>>> downtime so even if it goes smoothly there are at least two 
>>> additional days to account for the draining and ramp up of jobs in 
>>> which no work is done.
>>>
>>> cheers
>>> alessandra
>>>
>>>
>>> On 14/07/2011 10:21, J Coles wrote:
>>>>> Dear All
>>>>>
>>>>> (This is a general response not aimed at any particular 
>>>>> sites/people!)
>>>>>
>>>>> If the consensus is that the baseline release recommendation(s) is 
>>>>> (are) not in line with what is needed by the experiments and users 
>>>>> then we ought to feed that back to those setting the baseline. I 
>>>>> doubt it is critical at this juncture but there must be some 
>>>>> reason that it is deemed a baseline?
>>>>>
>>>>> I am slightly concerned that increasingly an argument being used 
>>>>> as to why a site will not upgrade is that we are in an accounting 
>>>>> period. The period is not set based on when sites need to be more 
>>>>> stable (the need is continuous). It may well be that we need to 
>>>>> have the accounting "period" as a continuous assessment to avoid 
>>>>> significant interruption at the start and end of these arbitrary 
>>>>> periods.
>>>>>
>>>>> Jeremy
>>>>>
>>>>
>>>>>
>>>>>
>>>>> On 14 Jul 2011, at 09:29, Sam Skipsey wrote:
>>>>>
>>>>>> Hi all.
>>>>>>
>>>>>> We pretty much decided in the storage group meeting yesterday 
>>>>>> that we
>>>>>> don't mind people not being at the Baseline Release, as long as
>>>>>> they're at 1.7.4.
>>>>>>
>>>>>> Sam
>>>>>>
>>>>>> On 14 July 2011 08:16, RAUL H C LOPES<[log in to unmask]>   wrote:
>>>>>>> On 12/07/11 11:11, [log in to unmask] wrote:
>>>>>>>> brought up at wlcg was services behond baseline. ( and 
>>>>>>>> continued usage of
>>>>>>>> glite 3.1)
>>>>>>>> baseline is here:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://twiki.cern.c<https://twiki.cern.cbrough/>h/twiki/bin/view/LCG/WLCGBaselineVersions<https://twiki.cern.ch/twiki/bin/view/LCG/WLCGBaselineVersions> 
>>>>>>>>
>>>>>>>>
>>>>>>>> For the record those reporting below these levels ( from wahid 
>>>>>>>> page) are:
>>>>>>>>
>>>>>>>> UKI-LT2-Brunel  httpg://dgc-grid-50.brunel.ac.uk:8446   DPM     
>>>>>>>> 1.7.2
>>>>>>>> UKI-LT2-Brunel  httpg://dgc-grid-50.brunel.ac.uk:8446   DPM     
>>>>>>>> 1.7.2
>>>>>>>> UKI-LT2-UCL-HEP httpg://lcg-dpm01.hep.ucl.ac.uk:8446    DPM     
>>>>>>>> 1.7.3
>>>>>>>> UKI-LT2-UCL-HEP httpg://lcg-dpm01.hep.ucl.ac.uk:8446    DPM     
>>>>>>>> 1.7.3
>>>>>>>> UKI-NORTHGRID-LANCS-HEP httpg://fal-pygrid-30.lancs.ac.uk:8443  
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>> UKI-LT2-Brunel  httpg://dgc-grid-38.brunel.ac.uk:8446   DPM     
>>>>>>>> 1.7.4
>>>>>>>> UKI-NORTHGRID-MAN-HEP   
>>>>>>>> httpg://bohr3226.tier2.hep.manchester.ac.uk:8446
>>>>>>>>      DPM     1.7.4
>>>>>>>> UKI-SOUTHGRID-CAM-HEP   httpg://serv02.hep.phy.cam.ac.uk:8443   
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>> UKI-SOUTHGRID-OX-HEP    httpg://t2se01.physics.ox.ac.uk:8446    
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>> UKI-NORTHGRID-LIV-HEP   httpg://hepgrid11.ph.liv.ac.uk:8443     
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>> UKI-NORTHGRID-LANCS-HEP httpg://fal-pygrid-30.lancs.ac.uk:8443  
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>> UKI-LT2-Brunel  httpg://dgc-grid-38.brunel.ac.uk:8446   DPM     
>>>>>>>> 1.7.4
>>>>>>>> UKI-NORTHGRID-MAN-HEP   
>>>>>>>> httpg://bohr3226.tier2.hep.manchester.ac.uk:8446
>>>>>>>>      DPM     1.7.4
>>>>>>>> UKI-SOUTHGRID-CAM-HEP   httpg://serv02.hep.phy.cam.ac.uk:8443   
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>> UKI-SOUTHGRID-OX-HEP    httpg://t2se01.physics.ox.ac.uk:8446    
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>> UKI-NORTHGRID-LIV-HEP   httpg://hepgrid11.ph.liv.ac.uk:8443     
>>>>>>>> DPM
>>>>>>>> 1.7.4
>>>>>>>>
>>>>>>>> UKI-SOUTHGRID-BRIS-HEP  httpg://lcgse02.phy.bris.ac.uk:8444     
>>>>>>>> StoRM
>>>>>>>> 1.3.19
>>>>>>>> UKI-SOUTHGRID-BRIS-HEP  httpg://lcgse02.phy.bris.ac.uk:8444     
>>>>>>>> StoRM
>>>>>>>> 1.3.19
>>>>>>> Hi Brian,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> UKI-LT2-Brunel  httpg://dgc-grid-50.brunel.ac.uk:8446   DPM     
>>>>>>> 1.7.2
>>>>>>>
>>>>>>> dgc-grid-50 is working fine, we're in the middle of an 
>>>>>>> accounting period,
>>>>>>> we have a lot of local users with data in that unit, and the 
>>>>>>> more I read
>>>>>>> about recent experiences with DPM upgrades the more I hate the 
>>>>>>> idea of
>>>>>>> starting it now. Plan is to upgrade it in a downtime in December.
>>>>>>>
>>>>>>> cheers,
>>>>>>>
>>>>>>> raul
>>>>>>>