perfsonar development work

["Michael Bischoff" <>]

Hello Verena,

As I wasn't up to speed I didn't realise where your coming from, but I do 
now(thank you for
clearing that up) and in that light the proposed solution makes sense.

That being said, I think the discussion is going to boil down to who knows 
how a service
works best. The service desk or the service developer, I would hope this is 
the latter.

Personally I would kick this back to the service desk and ask them the reason 
they
are gathering the data(the use case) Off course we can implement the test they
specify but. They should ask more abstract questions, because specific tests 
that
make sense against the current version of the service might not make any sense
against another as the architecture of the service might have changed. Not to 
think
the problems you encounter when you have two different implementations, for 
example
with flow-mp you probably want to check if nfreplay executable is there with 
our
implementation. But if someone implements a flow-mp based on a different tool 
flow4j
w/e it's silly to test if an nfreplay executable is there.

Because perfsonar is suppose to be implementation ambiguous you can't use 
specific tests
but always have to rely on more abstact test/questions. (is well configured?, 
is
operational? etc) The answer should (offcourse) be as specific as possible eg
('something' failed) isn't going to make anything happy.

This is also the reason why my proposal doesn't have to return one value, but 
could return
more then one. (errors that is as success(es) need(s) not to be reported back.
I'll add an example that also illustrates that(which I probably should have 
added
in the first place, sorry))

Verena: 'generic type of test and reporting back one single test result 
either stating
success or failure' the proposal was to report back sucess or failure _plus_
causes(errors) Which could be more then one(sorry for not making that clear)

Given all the above, to use jason's expression: I'm not married to anything, 
but the
issues that arise should probably be addressed.

Kind regards,
Michael


ps.
>> in the first place he wants a question to his/her answer
should offcourse be:
>> in the first place he wants a answer to his/her question
;-)

> Hi Michael, all,
>
>
> Am Freitag, 20. Juni 2008 21:38 schrieb Michael Bischoff:
>
>> Hello everybody,
>>
>>
>> See http://wiki.perfsonar.net/jra1-wiki/index.php/Talk:Service_Self-testing
>>
>>
> I added a comment to it.
>
>
>> More specificity which Verena's example: I really don't think a service
>> admin is interested in whether or not it could find an executable in the 
>> first place, in the
>> first place he wants a question to his/her answer: is the service 
>> correctly configured?(or
>> similar) If the answer is no then he cares about what he has to do to fix 
>> it. (and thus
>> wants to know why)
>>
> At the moment, this is not the point we are discussing about. The tests
> performed in this example were the ones we agreed on in Zagreb as the ones 
> the service desk
> (which in this case is the requester for the tests) wants to
> have. As to wether they are interested in such results or not, it's up to 
> them to decide. As
> they decided to have these tests, they get them. I personally think, that 
> the purpose of
> these self-testing feature was at first hand, to have exactly this kind of 
> information.
> However requesting more
> meaningful tests is of course on the agenda for a later stage.
>
>> see the link for a more complete story.
>>
>> I'm not sure what the additional complexity brings to the table.
>>
>>
> I responded to this on the wiki page.
>
>
>> Kind regards
>>
>>
>> Michael.
>>
>>
>> ps. there are more then one element with the same id now, I thought that 
>> was illegal.
>>
> Could be changed easily, thanks for noticing it.
>
>
> Regards,
> Verena