perfsonar development work

[Nicolas Simar <>]

Hi,

I got a list of questions so that everybody to give their opinion.

Why are everybody's opinion needed?
- because we are on a fairly tight schedule to provide the 
errors/discards functionality
- the safest bet is thus to go for a modification of the utilisation 
schema for catering with errors and discards.
- however, other options (as the SNMP unified proposal from Jason) can 
be a good opportunity that should be taken into account (e.g. for 
performances or for future proofing) and would thus be worth spending a 
little bit more time on it.
This is why a input is needed from the different developers (see in-line 
for the questions).

David Schmitz is about to send a summary of the different schema and the 
pros and cons to help you jump into this decision process.


Jeff W. Boote wrote:
> Nicolas Simar wrote:
>
> > Jason Zurawski wrote:
> >
> > > David;
> > >
> > > > Jason, from your point of view, which of the schema proposals could be
> > > > easily made ready for immediate use next week?
> > > >
> > > >   
> > >
> > >
> > >
> > > In my opinion we should proceed with the method that best maps 
> > > reality, not which is fastest to implement.  It would be great to 
> > > hear comments on both methods from various interested parties soon 
> > > (and if its next week you are looking to implement, comments need to 
> > > come *very* soon).
> >
> >
> > I guess that the interested parties are:
> > - the visualisation developers: Nina/Vedrin (psUI), David/Andreas 
> > (CNM), Daniel(visualperfSONAR)
> > - the web-service developers: Roman (RRD), Jeff/Jason (SNMP MP)
>
>
> I suspect it does not matter that much for the visualization developers. 
> They will need to start looking for additional schema/variables no 
> matter what. And, I suspect something similar to the current structure 
> should not be difficult for them. I believe Jason's proposal is much 
> more similar to the current structure than David's. (I do understand the 
> desire to retrieve multiple data types within a single data. Especially 
> from a visualization point of view. However, I think this would be a 
> complex thing to work into current services. The 'typed' datum is a 
> completely new concept.)
>
> For the service developers, I believe the main issue is how difficult it 
> is to extend the store to support multiple eventTypes. Multiples, no 
> matter the namespace add some complexity.

1) What does bring "support multiple eventTypes?
In a request, the capability of asking for linkUtilisation and 
inputErrros (so one request instead of several of them). Is that what it 
brings?

2) What are the benefits?

3) Who does need it? (or who might need it?)

4) How would it be used? (What do you foresee for such request)

5) Are there other means of achieving it?

6) If this was the chosen way, what would be the impact on modifying the 
existing code for
6.a) the visualisations?
6.b) the RRD and SQL MAs?

7) what is the similarities with what we got (syntax and semantics) as 
it triggers what will have to be re-written within a service.

8) What are the performances expectations? (better similar worse than 
sending multiple separate requests - assuming I understood properly what 
are those multiple eventTypes) [Can be answered at a later stage by the 
developers]

9) Backward compatibility: several projects are already using the 
existing schema for link utilisation. How can the backward compatibility 
be ensured for let's say at least the next two years?

> However, I think we can postpone some of the complexity (at least from 
> the perspective of the RRD MA) if we first support the errors/discards 
> from the characteristic namespace. This will reduce the number of nmwg 
> classes that Roman needs to create in support of this. (And, they end up 
> being near duplicates to the existing 'utilization' class - so it should 
> be trivial.)
>
> The SNMP MP implementation does not have complexity in this space 
> because it is using DOM for this - additional namespaces are just 
> handled at the query level - there is no 'marshalling' to worry about. 
> However, as I said - the multiple eventTypes are still an issue.
>
> Perhaps we should start the discussion with evaluating this part (how do 
> deal with multiple eventTypes) of Jason's proposal. (I like it, but I 
> was his sounding board for ideas...) It would be far better if others 
> commented.

I am assuming that both the RRD MA and the SNMP MP/MA would both be 
using at least one same schema so that compatibility can be provided to 
the user groups using those data.

Cheers,
Nicolas

> jeff
>
>
> > Nicolas
> >
> > > > Do you foresee an easy way starting with only the basic
> > > > features necessary (for next week), while not much complicating the
> > > > later integration of more complex features (e.g. tool namespace snmp)?
> > > >   
> > >
> > >
> > >
> > > Any or all of the standard we choose can be implemented to start 
> > > with, as long as everything is fully implemented in the end.  in my 
> > > opinion keeping things 'similar' to the characteristic style (similar 
> > > to utilization) is the fastest route to start with (both for getting 
> > > comments on this list and for allowing service developers to get 
> > > started).  No matter which method we choose it is imperative that 
> > > extension be possible in the future (i.e. to the SNMP namespace, etc.).
> > >
> > > -jason

--
Nicolas
______________________________________________________________________

Nicolas Simar
Network Engineer

DANTE - www.dante.net

Tel - BE: +32 (0) 4 366 93 49
Tel - UK: +44 (0)1223 371 300
Mobile: +44 (0) 7740 176 883

City House, 126-130 Hills Road
Cambridge CB2 1PQ
UK
_____________________________________________________________________