Fixing DPM might not happen but I am happy to escalate the issue. If someone points me at the bug report feature request.
> -----Original Message-----
> From: Alessandra Forti [mailto:[log in to unmask]]
> Sent: 21 February 2012 14:30
> To: Testbed Support for GridPP member institutes
> Cc: Gordon, John (STFC,RAL,ESC)
> Subject: Re: Ticket summary - 20th Feb 12
>
> 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/
> >>>
|