perfsonar development work

[Ilias Tsompanidis <>]

Michael Michalis wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
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

<nmwg:key id="localhost.-cc37e7:1156f72da26:643f">
               <nmwg:parameters id="localhost.-cc37e7:1156f72da26:6440">
                  <nmwg:parameter name="dataSourceMinValue">0</nmwg:parameter>
                  <nmwg:parameter name="dataSource" value="ds"/>
                  <nmwg:parameter name="dataSourceHeartbeat">2000</nmwg:parameter>
                  <nmwg:parameter name="dataSourceStep">300</nmwg:parameter>
                  <nmwg:parameter name="file" value="/opt/webapps//rrd-6610223421279004690.rrd"/>
                  <nmwg:parameter name="dataSourceMaxValue">10000000000000</nmwg:parameter>
                  <nmwg:parameter name="dataSourceType">garbage</nmwg:parameter>
               </nmwg:parameters>
</nmwg:key>


(which suggests that it created the rrd file with the given Heartbeat)

jra itsomp # rrdtool info /opt/webapps//rrd-6610223421279004690.rrd
filename = "/opt/webapps//rrd-6610223421279004690.rrd"
rrd_version = "0003"
step = 300
last_update = 1191836784
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 = "98760"
ds[ds].value = 0.0000000000e+00
ds[ds].unknown_sec = 84


The service seems to ignore the parameters given at the StoreRequest

Michalis
  

I suppose that this is a "dead" functionality, so I'll let aside
the crosschecking with the rrd file itself, and just check for rnc
compliance...

    

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFHCfqFoEWq51/Q/40RAhVbAKCVl5f8JDildbvv1ynM/+aGoYIsKwCdGe5A
QJfHiQvfTAK9n2CLQMmVJNM=
=+V82
-----END PGP SIGNATURE-----