perfsonar development work

[Loukik Kudarimoti <>]

Michael Michalis wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> Roman Lapacz wrote:
>   
> > Ilias Tsompanidis wrote:
> >     
> > > Michael Michalis wrote:
> > >       
> > Ilias Tsompanidis wrote:
> >
> >     
> > > > > > Szymon Trocha wrote:
> > > > > >
> > > > > >             
> > > > > > > Hi Ilias,
> > > > > > >
> > > > > > > Ilias Tsompanidis wrote:
> > > > > > >
> > > > > > >
> > > > > > >               
> > > > > > > > The store-eps-request.xml is the one that produces NaN.
> > > > > > > > Any ideas?  I get NaN also with store-eps-request2.xml
> > > > > > > > The first has optional parameter dataSourceType
> > > > > > > > ABSOLUTE and the latter GAUGE. The both created new rrd
> > > > > > > > files and I let them populate for at least 15 minutes.
> > > > > > > >
> > > > > > > > The rrdtool info output is : rrd_version = "0003" step
> > > > > > > > = 300 last_update = 1191585752 *ds[ds].type =
> > > > > > > > "COUNTER"* ds[ds].minimal_heartbeat = 1800 ds[ds].min =
> > > > > > > > 0.0000000000e+00 ds[ds].max = 1.0000000000e+13
> > > > > > > > ds[ds].last_ds = "U" ds[ds].value = NaN
> > > > > > > > ds[ds].unknown_sec = 152
> > > > > > > >
> > > > > > > >                 
> > > > > > > As you see your RRD file is still supporting COUNTER
> > > > > > > type. This is because the current implementation doesn't
> > > > > > > take into account these parameters from the request - it
> > > > > > > takes them from service.properties instead. So in fact in
> > > > > > > order to change it you would have to change
> > > > > > > service.properties file. To be honest you are probably
> > > > > > > the first person to try using store functionality. This
> > > > > > > was probably dead end as I haven't heard anybody using it
> > > > > > > in their network (everybody uses MRTG, Cacti, etc).
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > >               
> > > > > > The thing is that I'm trying to functional test it ;) So
> > > > > > I'm trying to produce a full test suite using the interface
> > > > > > specification doc:
> > > > > >
> > > > > >
> > > > > > Creation of rrd file requires many parameters. The service
> > > > > > is configured to use default parameters. However, if
> > > > > > parameters are passed in the parameter section right under
> > > > > > the message element, these parameters will be used instead
> > > > > > to create the rrd file.
> > > > > >
> > > > > > which obviously isn't quite there yet. And I've only used
> > > > > > the parameters that have already been introduced in the
> > > > > > document's examples. The rnc doesn't contain information
> > > > > > useful for the creation of rrd files.
> > > > > >
> > > > > >             
> > Hlias,
> >
> > can you test if a new rrd file is created when you pass new
> > parameters and if that rrd file complies with what the
> > parameterscontained? Maybe Roman can help you with that.
> >
> >
> >     
> > > > I used the following parameters to create a new rrd file via
> > > > storeRequest <nmwg:parameters> <nmwg:parameter
> > > > name="dataSourceStep">300</nmwg:parameter> *  <nmwg:parameter
> > > > name="dataSourceType">garbage</nmwg:parameter> <nmwg:parameter
> > > > name="dataSourceHeartbeat">2000</nmwg:parameter> *
> > > > <nmwg:parameter name="dataSourceMinValue">0</nmwg:parameter>
> > > > <nmwg:parameter
> > > > name="dataSourceMaxValue">10000000000000</nmwg:parameter>
> > > > </nmwg:parameters>
> > > >
> > > > You can see the dataSourceType should really create an error ,
> > > > and i changed the Heartbeat (1800 -> 2000). The keys returned
> > > > by storeResponse and setupDataResponse are the same
> > > >         
> > > Generally, the response key contains all parameters provided in
> > > the request metadata but those ones used to create rrd file are
> > > taken only from the config file (Szymon mentioned this in his
> > > email).
> > >       
> OK, but in documentation it is stated that if parameters exist inside
> the message then they override the default values. So if this
> functionality is to be supported in the fututre then either the
> documentation needs to change(stating that the datasource type is
> always COUNTER ant etc)  or the service implementation has to change,
> or maybe both (keeping COUNTER as standard is quite reasonable given
> the event types we are currently supporting)..
>   
I agree. I think documentation update is the best option as this 
interface is not used by anybody...

Thanks,
Loukik.
> Hlias,
> If you have finished your tests can you sum up your findings and send
> them to release mangmnt and Roman?
>
>
> Michalis
>
>   
> > > Roman
> > >       
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>  
> iD8DBQFHCgi3oEWq51/Q/40RAqTuAKCCIydFV+HA2HnQoLQE7ZuSRyscUQCgiqka
> NAFhVjDTzHXOBs3yIftDzRI=
> =/1GL
> -----END PGP SIGNATURE-----
>
>   


--

---------------------------------------------------------------
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