We all know this will not happen. Infact so far the max attention this 
problem has grabbed is today because someone else has to justify the 
situation.

cheers
alessandra



On 21/02/2012 13:43, John Gordon wrote:
> I agree with this but add that we should escalate the DPM issue/bug/feature.
>
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of Jeremy Coles
>> Sent: 21 February 2012 13:19
>> To: [log in to unmask]
>> Subject: Re: Ticket summary - 20th Feb 12
>>
>>> I commented because it needed to be noted that, as with the CE tests
>> (which everyone kind of fudges by getting them special queues or
>> whatever), the tests here are encouraging suboptimal behaviour in the
>> service of passing a metric.
>>
>> Living in a 'community' means that technically optimal solutions are
>> not always appropriate, though they might be our aim eventually. Even
>> if you are driving in the wrong direction for your destination, it is
>> still better to adopt the driving rules reached by consensus because
>> they are there for a reason.
>>
>> The metrics based on ops tests are useful; the escalation in this case
>> (noted several times in this thread) is whether we should raise a
>> discussion about the rule making the current selection of SE tests
>> critical. While we have that discussion (perhaps in the storage group?)
>> and feedback our views (I agree with John that) it would seem sensible
>> to implement the workaround and reduce the negative impact the result
>> is having.
>>
>> Jeremy
>>
>>
>>
>> On 21 Feb 2012, at 12:30, Sam Skipsey wrote:
>>
>>>
>>> On 21 February 2012 12:08, Daniela Bauer
>> <[log in to unmask]>  wrote:
>>> But the ops tests have been around for *ages* and the consequences
>>> known, so I don't think it'll suit us well to feign surprise right
>>> now. Just give ops 500 GB and be done with it.
>>>
>>>
>>> Who's surprised? This has come up before as a complaint about
>> centralised testing with a "non useful" VO, and there have been various
>> efforts at working around it
>>> (packaging tests in randomly selected job wrappers, for example).
>>>
>>> I commented because it needed to be noted that, as with the CE tests
>> (which everyone kind of fudges by getting them special queues or
>> whatever), the tests here are encouraging suboptimal behaviour in the
>> service of passing a metric.
>>> It is, of course, the case that this fact isn't going to change
>> anything, but it seemed that someone should note it, again.
>>> [Again, Glasgow, for example, passes Ops storage tests partly because
>> the ops tests don't talk to the same filesystems that ATLAS use. The
>> ops tests, therefore, do not actually test
>>> the functionality of the overwhelmingly most important filesystems
>> for the availability of Glasgow as a functional site.]
>>> Sam
>>>
>>>
>>> Daniela
>>>
>>> On 21 February 2012 12:05, Sam Skipsey<[log in to unmask]>
>> wrote:
>>>>
>>>> On 21 February 2012 11:45, Stephen Burke<[log in to unmask]>
>> wrote:
>>>>> Testbed Support for GridPP member institutes [mailto:TB-
>>>>>> [log in to unmask]] On Behalf Of John Gordon said:
>>>>>> If this has been a long-standing DPM issue then I will ask to
>> have this
>>>>>> test (SRMput ?) removed from the SRMV2 set of tests so that it
>> isn't
>>>>>> included in availability.
>>>>> Even if there really was no free space for ops, does that make the
>> SE
>>>>> unavailable? Any VO may fill up its space, that doesn't mean the
>> site is
>>>>> broken. Probably the intention is that the test is just supposed
>> to verify
>>>>> the functionality and no-one has considered the possibility of it
>> being
>>>>> full. (CE tests are similar if the queues are full - there I think
>> most
>>>>> sites do have an explicit reservation just to let the ops tests
>> run.)
>>>> This is a valid point, and what I was getting at with my nagios
>> test
>>>> comment: the test doesn't test if the storage is available, it
>> tests if ops
>>>> can write to the storage. (Now, obviously, there's a point at which
>> you have
>>>> to consider that a test has to test *something*...). ATLAS,
>> meanwhile, can
>>>> happily write to the storage; and even ops tests are happy talking
>> to the
>>>> storage, and it is responding in a reasonable and sane way.
>>>>
>>>> I note that Manchester is an almost entirely ATLAS site. It seems
>> reasonable
>>>> that their availability be determined by their being available for
>> the
>>>> entities that they are supposed to be supporting in the main,
>> surely?
>>>> Sam
>>>>
>>>>> Stephen
>>>>
>>>
>>>
>>> --
>>> -----------------------------------------------------------
>>> [log in to unmask]
>>> HEP Group/Physics Dep
>>> Imperial College
>>> Tel: +44-(0)20-75947810
>>> http://www.hep.ph.ic.ac.uk/~dbauer/
>>>