perfsonar development work

[Jason Zurawski <>]

Nina Jeliazkova wrote:
> Jason,
>
> Could you (roughly) specify a list of queries to troubleshoot an LS
> (gLS, hLS, in this particular case and if possible generic) - it would
> be good to have them readily available in the playground tab.


Simple queries should be used to debug database problems, for examples 
see the source of the view.cgi script:

http://anonsvn.internet2.edu/svn/perfSONAR-PS/branches/RELEASE_3.1/perfSONAR_PS-perfAdmin/cgi-bin/

This sends 6 queries (XQueries) to get at the major parts of the hLS/gLS.

As for debugging further, its really not something I would be able to 
predict.  Perhaps something that returns matched sets of metadata/data 
by service name.  There are probably examples of how to do this already.


> Also, will be good to know which of the queries can be issued via client
> API above the level of raw queries.


I can't really speak for the current development of the Java API, if it 
is following what is outlined in the design document (being able to 
query for domain/IP/eventType/keyword/service information) this should 
be enough to test what is available.

-jason


> Best regards,
> Nina
>
> Jason Zurawski wrote:
> > 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