Sorry I am missing the meeting today but I am in the storage part of the GDB. In which it was just announced that
DPM 1.7.4-6 certified
– Periodic cleanup of request database
– Fixes free space reporting in dpm-listspaces
– Allow setting of RFIO buffer size on client side
– Various bug fixes
Apparently this was certified in a week - so we are moving along faster now!..
I am tempted to move to this version but I agree that we should have some sort of evaluation for what version is recommended.
Wahid
On 11 May 2010, at 17:12, [log in to unmask] wrote:
> I won't offer an opinion on if the Tier-1 change control process could be usefuly adapted to storage system upgrades but can say a bit about it.
>
> The main purpose of our change process is to ensure that when we introduce a change its been properly thought through
>
> - We know what is going to be changed (who uses it, how critical it is etc)
> - Whatthe benefits are
> - testing has been appropriate (to the level of risk)
> - A coherent change implementation plan exists
> - A reversion plan has been considered
> - Appropriate announcements are planned
> - Thought has been given to residual risks
> - The change has been considered by a team of people to help spot oversights, unexpected dependencies etc.
>
> The issue here is a bit different but I see parallels. We have found that there is benefit in formalising the process
> of assesing a change. One key part though is the actual meeting where we all get our heads together and assess the issues associated with the change and push back when we think a submittor can do better. Not sure quiet what the parallel is here. I guess its something like -
>
> some bright spark suggests T2s should upgrade to release X of product W without really thinking through the implications of the upgrade or assessing the quality of release X. T2s go ahead and do it without realising that they are embarked on a risky enteprise with no way back etc etc.
>
> regards
> Andrew
>
>> -----Original Message-----
>> From: GRIDPP2: Deployment and support of SRM and local storage
>> management [mailto:[log in to unmask]]On Behalf Of
>> [log in to unmask]
>> Sent: 11 May 2010 15:38
>> To: [log in to unmask]
>> Subject: Re: Potential new golden DPM...
>>
>>
>> Hey! So an issue myself and Jens have briefly discussed is
>> the decision
>> process on when to recommend sites to upgrade. Ie do a risk assessment
>> of the upgrade and a cost/benefit analysis of problems vs.
>> improvements.
>> Was beginning to look for terms an constraints.
>> Ie do benefits of upgrade affect multiple/single VOs? Which ones?
>> Does the upgrade provide an ability which is
>> necessary/requested/superfluous?
>> What is the chance the upgrade?
>> The Tier 1 now has a change control procedure, I though
>> perhaps adapting
>> this to apply for Storage upgrades at T2 would work?
>> Comments? ( especially form those at the Tier1 who have been
>> part of the
>> change control process as to whether this is a sensible idea in the
>> first place !!)
>> Regards
>> Brian
>>
>>
>> -----Original Message-----
>> From: GRIDPP2: Deployment and support of SRM and local storage
>> management [mailto:[log in to unmask]] On Behalf Of Sam
>> Skipsey
>> Sent: 11 May 2010 15:22
>> To: [log in to unmask]
>> Subject: Potential new golden DPM...
>>
>> Hello all,
>>
>> DPM 1.7.3 has been out for more than a month now, and no-one has
>> complained yet(!).
>> One of the improvements of 1.7.3 over the previous releases is that it
>> contains a workaround for brokenness in the lcg_utils library. That
>> is: 1.7.3 will store checksums requested by lcg_utils functions (like
>> lcg-cr).
>>
>> ATLAS would like to be able to rely on checksums they request being
>> stored by the SE. I would imagine this is also true for other VOs. So,
>> whilst it isn't Golden yet, I'd like to encourage everyone to
>> move their
>> DPM to 1.7.3 if possible.
>>
>> (I've done it just now on svr025, and it seemed to be very
>> straightforward. svr018 will be moved as soon as I've finished some
>> drains I'm doing.)
>>
>> Sam
>>
>
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
|