perfsonar development work

[Nicolas Simar <>]

Hi David,

Thank you David for this summary.

I would like to schedule a conf call for Thursday to finalise the 
gathering of information that will help us to take a decision (short 
term and for the schema unified proposal) and take a decision about what 
path to follow. If the discussion has reached an agreement before 
Thursday, they the meeting will be canceled.

Thursday, the 2nd of August, 16:00 CEST, 10:00 EST.
Expected participants: at least: Nina, Jeff, Jason, Roman, David, Danijel.

Keep an eye on the questions I raised (in particular backward 
compatibility) previously as they will come back.

Best regards,
Nicolas


David Schmitz wrote:
> Hi all,
>
> the development of the snmp ifError/ifDiscards MA will start rather soon 
> (next week) and there are still issues to discuss.
> As probably not all people had time to follow the discussion in the
> mailing list recently, I give a short summary about the schema being 
> developed for this new type of MA:
>
> In general, this type of MA will be similar to the utilization MA,
> but it will support multiple metrics:
> There are two new snmp metrics to support with this new type of MA
> at the moment: ifErrors and ifDiscards (frame drops),
> more metrics may be added later.
>
> Jason has proposed 2 different possibilities for the new schema,
> while I myself simultaneously proposed another one:
>
> Jason's first solution is very similar to the existing schema for the 
> utilization MA.
> Here, in fact, for both new metrics (errors and discards) separate
> schemas and namespaces (each similar to the utilization schema) are used.
> The advantage of this possibility is that the adaptation from the existing
> utilization MA to the new MA is very easy, and not much changes should
> be required in the MA code.
> As the developing of the new MA will start next week very soon, we should 
> using
> this solution in the beginning.
>
> Jason's second solution is a unified solution covering any SNMP metric, 
> i.e. utilization, errors, drops, and new ones to come in the future.
> This single schema uses different event types for distinguishing
> between the different metrics.
> Above all, it supports a wildcard eventType covering all available metrics.
> The advantage of this schema is that it allows to fetch the data for multiple 
> metrics
> of a single subject (e.g. an ip link) without specifying the subject twice in 
> the request.
> So it probably allows for a better performance.
> Further, the integration of new SNMP metrics is possible.
> This solution is of course more complex than the first one and MA Service developers 
> will have to check the effort to adapt their services to this new schema.
> The openness for the future of this unified approach should be
> discussed, i.e. if it really is sufficient for all new metrics to come.
> We should not have to change the existing schemas too often.
> Specifically, we have to take care of the compability with the existing
> utilization schema.
>
> Additionally, I myself proposed a schema for error and drops which
> lies more or less between Jason's proposals.
> My idea was to have a single schema for the two new metrics.
> As Jason already addressed this issue with his second approach 
> (even integrating utilization) 
> and he is more involved in NMWG schema development, it's probably better to
> start with his proposal instead of my own.
>
>
> Best Regards,
> David
>
>
> > 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.
> >
> > 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.
> >
> > 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
_____________________________________________________________________