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/
> >
|