perfsonar development work

["Jeff W. Boote" <>]

On Feb 9, 2009, at 5:26 AM, Jason Zurawski wrote:

> Roman Lapacz wrote:
> > Jeff W. Boote wrote:
> > > From reading Jason's email, I think that I was perhaps not clear.
> > >
> > > I favor only having 'throughput' - I think 'value' is confusing  
> > > for tools that provide multiple types of values.
> > >
> > > The question for me is one of backward compatibility. If there are  
> > > clients out there that expect to see the throughput in a 'value'  
> > > attribute, I think we should provide it that way in this version  
> > > but deprecate it. And also provide the exact same data in a  
> > > throughput attribute so that clients can move to the new method.
> > >
> > > If we don't have clients to worry about here - then I think we  
> > > should immediately drop 'value'.
> > I agree. Previously I stated that 'value' is fine for me because I  
> > thought it's important for backward compatibility. If it's not we  
> > should remove it.
> > So the question is: which client app needs 'value' field? Verena,  
> > Do you know how is it in pSUI? Jason and Jeff, do you have other  
> > client app depending on this?
>
>
> Our cgi scripts are easy enough to change.
>
> I am still uneasy about this entire conversation because I don't  
> believe that we are representing the best interests of other  
> services.  Martin had pointed out in previous conversations that it  
> is desirable to maintain the time/value pair for simplicity in  
> service and API design (Jeff alluded to this as well below).  No  
> matter what 'type' of service is being queried, the resulting datum  
> should deliver these two attributes.  I agree with this idea  
> conditionally, namely because tools such as iperf may have several  
> candidates for 'value' and this complicates the choice by the author  
> and the expected value to the user.

There are several schema's that do not have 'value' in them currently.

> If we do eliminate 'value' from this schema, there may be other  
> services/schemata that could be re-evaluated to eliminate a generic  
> term such as 'value' in place of more descriptive items such as  
> 'latency', 'throughput', or 'delay'.  This is too slippery of a  
> slope in my opinion, so allowing a questionable tool like iperf a  
> pass on this issue doesn't seem reasonable.

The slippery slope can be applied the other direction as well... Do we  
now have to go through the existing schemata and look for ones that do  
NOT use value?

I personally think that most tools provide more than one piece of  
information, and often it is dependent upon context what the  
'interesting' information you want.

I do think value makes sense for things in the 'metric' namespace, but  
I'm not convinced it should be required for eventTypes in the 'tool'  
namespace.

> Half of my $.02 after thinking about this is that 'value' should  
> probably stay, if we want compatibility this means that it should  
> ride alongside 'throughput' for future releases with a sunset date  
> for when 'throughput' stops being supported.  This will complicate  
> APIs for the very short term, but eventually we can go back to a  
> time/value expected behavior.  The other half of my $.02 is that  
> trying to quickly decide the fate of this issue isn't a good idea.   
> I know our face to face meetings are getting further and further  
> apart, but discussing this in a wider forum may help.

I think perfsonar-dev is a wide enough forum (and likely wider than  
any f2f we could have) to decide.

If anyone is currently using 'value', than lets keep it along with  
throughput. If not, then this is a non-issue.

jeff

> -jason
>
>
> > Roman
> > > jeff
> > >
> > > On Feb 6, 2009, at 9:52 AM, Jason Zurawski wrote:
> > >
> > > > All;
> > > >
> > > > In the end I dont have a strong opinion either way. Just note  
> > > > that we do have many legacy pSBs on Knoppix disks that will  
> > > > always report 'throughput'. If we want future versions to report  
> > > > 'value', 'throughput', or even both I can do that, but for  
> > > > Roman's sake he may need to recognize both for the foreseeable  
> > > > future.
> > > >
> > > > If we want to be consistent with other tools I suppose sticking  
> > > > with value is appropriate, but I feel its less descriptive for  
> > > > something like iperf that does report several 'values' for  
> > > > output. I am sure there are more tools out there in the same  
> > > > boat, so sticking with the value paradigm just because  
> > > > 'everything else does it' doesn't completely convince me.
> > > >
> > > > -jason
> > > >
> > > >
> > > > > I don't think it is such a good idea to keep both value and  
> > > > > throughput. This complicates clients since they will not know  
> > > > > which one a particular service will use. I can see doing this as  
> > > > > part of a well defined transition plan - for example this  
> > > > > version of the service MUST specify both so that old clients are  
> > > > > not broken, and value is expected to be removed in the next  
> > > > > major release.
> > > > > Just letting service use which ever one they want is not nice  
> > > > > for clients. (Or am I mis-understanding?)
> > > > > jeff
> > > > > On Feb 6, 2009, at 6:39 AM, Roman Lapacz wrote:
> > > > > > Verena Venus wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Am Friday 06 February 2009 14:23:24 schrieb Roman Lapacz:
> > > > > > >
> > > > > > > > Jason Zurawski wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Jason,
> > > > > > > >
> > > > > > > >
> > > > > > > > > > The schema does not have 'throughput' or 'jitter' elements.
> > > > > > > > > Corrected in my doc and the iperf schema in the main pS  
> > > > > > > > > repo. Jitter
> > > > > > > > > *should* have been there since this is reported by iperf UDP  
> > > > > > > > > tests.
> > > > > > > > >
> > > > > > > > > Throughput is more descriptive than 'value' in my opinion  
> > > > > > > > > (since there
> > > > > > > > > are many 'values' that can be returned by an iperf test). I  
> > > > > > > > > have
> > > > > > > > > added throughput to the schema but kept value for now in  
> > > > > > > > > case VV or
> > > > > > > > > anyone else has a use for it.
> > > > > > > > >
> > > > > > > > > I think we should talk about deprecating the attribute or  
> > > > > > > > > perhaps
> > > > > > > > > allowing it to stay with a use that will vary by service (I  
> > > > > > > > > would
> > > > > > > > > prefer the latter).
> > > > > > > > The latter is fine for me as well.
> > > > > > > >
> > > > > > > > I've just created RC1 of Java SQL MA v.2.1.1 with iperf stuff  
> > > > > > > > and
> > > > > > > > previous schema. On Monday I will create the new one (RC2)  
> > > > > > > > with your
> > > > > > > > updates (compatibility has hight priority!).
> > > > > > > >
> > > > > > > >
> > > > > > > > Verena, any comments on changes?
> > > > > > > It would be nice, if you could send me the new schemata/ 
> > > > > > > examples when everything is settled. I can do the changes then  
> > > > > > > very quickly.
> > > > > >
> > > > > > I will updated the service and message examples and send them  
> > > > > > to you on Monday.
> > > > > >
> > > > > > Roman