perfsonar development work

["Luchesar V. ILIEV" <>]

Hi Jason,

Just a brief pre-reply, really. Like I said, I understand your concerns 
very well (or at least I can see the very good points you make.) The 
difference in our views is most likely due to the fact that I'm looking 
with the eyes of a UNIX administrator dealing with simple, hard-core 
network services. Put in the mix the fact that my primary duty is 
security officer of our NREN, and you'll realize perhaps why I swear by 
simplicity and robustness.

The fact is that I've never felt involving the web messages in this type 
of monitoring a good idea at all. Exactly for the reasons above, I want 
them to be as simple as possible, but yes, you're absolutely right, this 
simply could destroy something that is so carefully planned.

To give an example again, like in the previous mail, you can't really 
use a Lamborghini Murcielago to clean up a pile of rocks blocking the 
road. Well, you can, actually, but then, well, the Lamborghini designers 
will crucify you, and rightfully so... ;D

Unfortunately, we have the road blocked by that pile of rocks, and at 
the moment we only have the fine Murcielago at hand. But I trust we can 
find a way to not ruin it, indeed, while still reaching our goal. :) So, 
no offence taken, indeed: the argument is definitely helpful. :)

Really time to lend myself to Morpheus, I'm afraid. :\

Cheers,
Luchesar



Jason Zurawski wrote:
> Luchesar & Jeff;
>
>
>>> I can see the desire for a simple generic test request. However, the
>>> resulting response should be equally simple. The current proposal
>>> does not fit that in my opinion.
>>>
>>> For a simple generic case, I would expect a result to only have a
>>> simple result code and a human readable status message with more
>>> details.
>>
>> 1) Regardless of what a service does while self-testing, there are
>> only two possible result codes: "success" and "error". "Success" is
>> defined as the result where all internal checks have passed
>> successfully. Any single error encountered will result in error 
response.
>>
>> 2) The datum-s in the data element hold all relevant messages, _in_
>> human-readable format: exactly the same that are sent via syslog.
>>
>>> Something very simple like that I could see supporting in our
>>> services as well. However, the current proposal is a bit convoluted
>>> for me.
>>
>> I'm afraid, I really can't see what's convoluted in this proposal, but
>> I'd be happy to explain further if you are more specific about what
>> worries you, and I haven't somehow already answered it.
>
>
> Jeff's concern is exactly the same as mine.  We are not opposed to the
> information you are proposing to send back in the message; it is clear
> you put a great deal of thought into being sure everything is included
> and it all makes it back in the response.  We are opposed to *how* it is
> being returned and what would be subsequently required to decoded the
> content by services and clients alike (this is what I interpret Jeff's
> 'convoluted' comment to mean).
> The proposed method works fine for a single test because there is no
> guesswork involved when there is a single datum (it MUST belong to the
> metadata/eventType).  With the proposed 'fulltest', it is necessary to
> rely on regexing the results to search for content.  Because we have
> carefully designed mechanisms meant to link metadata and data (no matter
> if its a command to a service or measurement information) we would like
> to see something that incorporates a self describing format instead of
> relying on text globs.
>
>
>>> It seems clear that you all need to implement something fairly
>>> quickly for this. And that it may not be something that the full
>>> group of perfSONAR services want to support.
>>
>> Would you please explain why any one service wouldn't like to support
>> something as simple as self-test? And I'll assume it's simply my
>> imagination seeing the first sentence trying to imply something.
>>
>>> I would suggest you create your own namespace for this, so it is
>>> outside of the 'perfsonar' namespace. Things in the perfsonar
>>> namespace should probably be reviewed more thoroughly (and will be
>>> specified by the new OGF group). Several of you have already noted
>>> that this should be enhanced in the future - so it seems clear that
>>> we don't really know what should be here yet.
>>
>> I agree with you that I hardly have the necessary expertise to impose
>> my ideas on the community. I wouldn't agree, though, if you imply a
>> wider group of people to be incompetent enough. But one way or the
>> other, "imposing" has never been my idea, really. As you can see, I'm
>> seeking the opinion of everyone, including yours, and I do appreciate
>> and respect all that were shared. I do apologize, if somehow I made
>> the wrong impression, yet it must have been obvious that I'm very open
>> to criticism and advice.
>>
>> All that said, I understand your worries about the clear view of the
>> namespace structure and contents, and I totally concur that all
>> changes and additions must be well thought about. However, in my
>> experience, if you do want to get a product ready and have it
>> presented, trying to get the things perfect might very easily end in a
>> "Vista-like" situation (unfortunately, these cases show also that
>> however long you might be perfecting something, in the end it might
>> turn out to be quite far from perfect actually.) Trust me, I know that
>> too well constantly making that mistake (including with that very
>> current task.)
>>
>>> If you use your own namespace, you can get some operational and
>>> development experience for what works and use that to make
>>> recommendations for what should be in the perfsonar namespace in the
>>> future, ok?
>>
>> Jeff, although I do feel something very worrying in how you say this,
>> I trust you're really just very much concerned to have something not
>> being ruined from the very beginning. I can see your point, and I
>> would agree with you, but I'm definitely not the person to decide.
>
>
> Before we go too far down dark paths here, I don't think Jeff was
> suggesting that anyone would simply refuse to support testing, just the
> form of testing that would only benefit MDM services and/or help desk
> operation.  There are several services within the framework that will
> not become a part of MDM, so in my opinion those service authors may not
> feel very compelled to spend extra time implementing a given feature 
when:
>
>  a) it's a one off for a specific purpose
>  b) it will become better defined in the future.
>  c) only one client exists to consume the results
>
> Our concern is that in implementing extensions to any of the basic
> building blocks must be done carefully to ensure extensibility,
> flexibility, and correctness to the rest of perfSONAR.  I previously
> stated that what you have done is not wrong, its just not how I would
> have solved the problem and it seems that we are in some agreement that
> it can be done differently sometime later.  As such I can't see spending
> development cycles to ensure my service responds to this query (not
> being in MDM) or develop clients capable of reading the resulting
> messages when there is a desire to go with a more structured approach
> further down the road.
>
> The suggestion of a different namespace was also not meant to offend,
> here are some good reasons why:
>
> - An MDM specific namespace ensures you can encode it however you want,
> e.g.: <mdm:datum test="test eventType uri" result="test result uri">SOME
> MESSAGE</mdm:datum>
> - Only services designed to send and receive this special type need to
> care.  E.g. we have several services that are perfSONAR, yet not MDM.
> We of course will be implementing some type of test procedure, but will
> not have a service desk constantly sending predefined tests over time
> and therefore would favor a more precise eventType/result structure that
> I alluded to. - The data can be branded as MDM specific, and potentially
> stored outside of just syslog.
>
> As you pointed out, we are just concerned with getting it right the
> first time, which can be frustrating, but I think we are getting
> closer.  I would be interested in seeing the wiki pages you alluded to
> in the first email (I have only see the one link so far and couldnt seem
> to locate anything else on the wiki), that would probably be more useful
> to me than exchanging XML over email.
>
> -jason

Attachment: signature.asc
Description: OpenPGP digital signature