perfsonar development work

[Jason Zurawski <>]

Szymon Trocha wrote:
> Hi Jason, all,
>
> Jason Zurawski pisze:
> > Things that I thing need to be answered to debug further:
> >
> >  - Why did the hLS stop registering and what is it's registration 
> > interval?  This is one more reason why the registration intervals (all 
> > intervals really) are important and why adjusting the protocol around 
> > the idea of the LSTTL is a very hard problem to solve.
> >
> >  - Are my design assumptions (above) correct about how the gLS should 
> > behave regarding cleaning out information and making summary sets.  I 
> > say yes - but we may also want the summary set to die immediatly after 
> > an hLS does so we don't introduce false positives as Nina is seeing.
> >
> >  - Is the lack of a summary set in the hLS view.cgi indicitive of this 
> > service not registering to the gLS.  I think the two may be related, 
> > but I do not know too much about the MDM hLS architecture.
>
> Would it help you to have access to some testing instance of MDM-LS?
> The current LS you picked up is from the production environment so it 
> may be difficult to play with it and moreover only Service Desk has 
> direct access to it.


Testing against a live instance used for MDM monitoring is not a great 
idea, but this is a particular machine that is known to be behaving 
funny (I have not looked at other MDM instances but we probably should 
if we discover something wrong here).  I do not need access to a test 
instance since my queries are non-destructive.

I would be interested to know:

 - Is this hLS summarizing and where is the data stored.

I tried Slawomir's suggestion of a query to find the missing summary data:

    <xquery:subject id="sub1">
      declare namespace nmwg="http://ggf.org/ns/nmwg/base/2.0/";;
      
/nmwg:store[@type="LSStore-control"]/nmwg:metadata
    </xquery:subject>

<nmwg:eventType>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</nmwg:eventType> 


This does not work either, all I got back were the control metadatas. 
If we can figure out *if* this service is summarizing and where it is 
storing the data, that would be a good first step.  Some other things 
worth knowing:

 - Which gLSs it is contacting to register
 - How often it is registering (if it is registering)
 - Errors the gLSs may return if registration is failing

The last 3 seems like a good task for the service desk since they have 
access to the logs.


> What kind of testing can we do to narrow down the problem?


The best testing in my opinion is using a simple client to interrogate 
the LS data set.  If the client can't get at the data, that makes me 
think there is no data.

-jason