perfsonar development work

[Loukik Kudarimoti <>]

Hi Jeff,

I support this move. I think that this effort should compliment a good 
protocol versioning practice (on the lines of what we discussed @ LBL). 
Without good protocol versioning, this will be of very little help.

Loukik.

Jeff W. Boote wrote:
> Hi All,
>
> I'm bouncing this relmgmt message out to the full development list, 
> because I think it is something we need to address more firmly across 
> the full development effort. Not just within the release management team.
>
> I want to propose a direction for future developments. (Note, I'm not 
> proposing the solution for this particular release. I'll leave that up 
> to the relmgmt team. I'm just seeing the same problem come up in 
> different forums, and this seems like a good example to illustrate a 
> possible solution.)
>
> I agree with the directions Roman has gone here. These changes are 
> needed to maintain consistency between multiple data types as Roman 
> has suggested. However, it is clear that the changes has caused some 
> interoperability problems with clients. So, we need a better migration 
> strategy for these kinds of modifications in the future.
>
> Jason and I talked about this particular problem some because it also 
> effects the pS-PS SNMP MA. (And we have had some discussion about 
> other similar problems in our pS-PS development team.)
>
> In a discussion we had yesterday, Martin suggested that there are 
> three levels of things that need to be standardized in some way:
>
> 1) schema
> 2) protocol (generic service level)
> 3) profile (specific data types in a service)
>
> I agree with this. But, we do not adequately have this represented in 
> our client/service interactions (or documentation).
>
> Currently, the 'schema' level is described in our messages (using the 
> eventType).
>
> The 'protocol' level is not really described yet, but it seems clear 
> that it needs to be.
>
> I *think* the 'profile' can be adequately described by a combination 
> of 'schema' and 'protocol'. (But, we can add something more later if 
> this turns out to be false.)
>
> I would like to propose the following for the future:
>
> A message level parameter to indicate the 'protocol' type and level.
>
> <nmwg:parameters>
>     <nmwg:parameter name="pSprotocol">
>     http://perfsonar.net/ns/protocol/MA/${date}
>     </nmwg:parameter>
> </nmwg:parameters>
>
> Clients would specify the version they expect the service to use. 
> Services should report back the version they are using or a response 
> code indicating the requested protocol level is unsupported 
> (preferably with a supported range of protocol versions). [Response 
> codes must be given in a way that is acceptable to the client. This is 
> one area where backwards compatibility will need to run a long ways.]
>
> In this way, a service can support a specific range of protocol 
> message semantics. And it has a way to indicate how much backwards 
> compatibility it will support.
>
> This could be used to deal with this current backwards compatibility 
> issue in this way:
>
> If the 'client' sets this message level parameter, then the RRD MA 
> could respond with the datum in snmp:datum elements, if not - then it 
> can use nmwg:datum. (Likewise for the other issues described here.)
>
> jeff
>
> Loukik Kudarimoti wrote:
> > Roman,
> >
> > As highlighted in bugs 221, 222, there are backwards incompatible 
> > changes to the way in which utilization data is retrieved from the 
> > new version of RRD MA. I suggest a phone conference tomorrow to plan 
> > on resolving these issues
> >
> > Suggested time: 12:00 hrs UK time, 13:00 hrs PSNC time
> > Expected attendees: Loukik, Luis(?), Michalis, Szymon, Roman, Nicolas
> >
> > thanks,
> > Loukik.
> >
> > Roman Lapacz wrote:
> > > Loukik Kudarimoti wrote:
> > > > Hi Roman, Szymon,
> > > Hi
> > > > I welcome the discussions on schema and changes being made in the 
> > > > trunk of RRD MA. What I don't understand is why it has been decided 
> > > > to have these schema changes released as part of the update at this 
> > > > stage. It clearly breaks backwards compatibility.
> > > >
> > > > I am aware that Nicolas wanted new metrics to be released as part 
> > > > of perfsonar-bundle 2.2 version but there was no mention/need to 
> > > > release these schema changes. Right?
> > >
> > > For those new metrics the namespaces of datum elements are tied to 
> > > eventTypes so the utilization should follow the same approach to 
> > > keep consistency between messages (messages for utilization, errors 
> > > and discards are very similar).
> > >
> > > Replacing supportedEventType  parameter is a change which effects 
> > > metadata service configuration so it should not harm the 
> > > communication with clients.
> > >
> > > Roman
> > >
> > >
> > > > Loukik.
> > > >
> > > >
> > > >
> > > >  wrote:
> > > > > http://bugzilla.perfsonar.net/show_bug.cgi?id=221
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------- Comment #1 from   2007-09-24 08:40 
> > > > > -------
> > > > > (In reply to comment #0)
> > > > >  
> > > > > > Serious ones:
> > > > > > 1. As an effect of removal of parameter SupportedEventTypes in 
> > > > > > the metadata
> > > > > > config, some of the service responses have been altered. 
> > > > > > Following requests in
> > > > > > the interface spec for RRD MA 2.2 have been modified and thus 
> > > > > > resulted in
> > > > > > incompatibilities:
> > > > > > - Page 13, example 2  (compare with Page 16, example 2 in 2.3 spec)
> > > > > > - Page 18, example 8  (compare with Page 21, example 8 in 2.3 spec)
> > > > > > - As a result LS registration information format changes as well.
> > > > > >     
> > > > >
> > > > > supportedEventType parameter in metadata configuration file is not 
> > > > > supported
> > > > > any more. eventType element has replaced it. This was agreed with 
> > > > > Jason and
> > > > > Jeff on dev mailing list some time ago and it's used in perl 
> > > > > implementation as
> > > > > well.
> > > > >
> > > > >  
> > > > > > 2. Chained requests not supported any more
> > > > > > - Pages 21- 27, examples 11, 12, 13, 14  are not supported anymore
> > > > > >
> > > > > > 3. Even though the documentation states that the response datum 
> > > > > > for utilisation
> > > > > > uses nmwg namespace and the datum for drops and discards uses an 
> > > > > > event type
> > > > > > based namespace, the implementation is different. All datum 
> > > > > > returned use a
> > > > > > namespace defined by the eventType. This raises serious backwards
> > > > > > incompatibility with 2.2
> > > > > >     
> > > > >
> > > > > Documentation has been updated. Namespace of datum element is tied 
> > > > > to eventType
> > > > > element (agreed with Jason and Jeff).
> > > > >
> > > > >  
> > > > > > Less serious ones:
> > > > > >
> > > > > > 4. Key contents have been changed (But keys are expected to be 
> > > > > > opaque. So, it
> > > > > > shouldn't matter. We need to make it known to other dev teams 
> > > > > > though)
> > > > > >     
> > > > >
> > > > > select parameter elements are not put in parameters element of 
> > > > > nmwg namespace.
> > > > > They are grouped according to namespace.
> > > > >
> > > > >  
> > > > > > 5. For utilisation, both namespaced and non-namespaced eventTypes 
> > > > > > were
> > > > > > supported in 2.2. This *seems* to have been changed to support 
> > > > > > only namespaced
> > > > > > eventTypes. This, we think, is an acceptable deprecation and 
> > > > > > *should* have
> > > > > > minimum impact on the client developers
> > > > > >     
> > > > >
> > > > > Right. We want to support only namespaced eventTypes and this was 
> > > > > announced
> > > > > some time ago on mailing list by Szymon.
> > > > >
> > > > >  
> > > > >
> > > > >   


--

---------------------------------------------------------------
L o u k i k   K u d a r i m o t i

     * *              Network Engineer
   *     *            City House, 126 - 130, Hills Road
  *                   Cambridge CB2 1PQ, United Kingdom
  *                   WWW: http://www.dante.net
D  A  N  T  E          Tel:+44 1223 371300 Fax:+44 1223 371371