Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Re: Store request in RRD-MA 2.3. rc3

Subject: perfsonar development work

List archive

Re: [pS-dev] Re: Store request in RRD-MA 2.3. rc3


Chronological Thread 
  • From: Michael Michalis <>
  • To: Roman Lapacz <>
  • Cc: Ilias Tsompanidis <>, perfsonar-dev <>
  • Subject: Re: [pS-dev] Re: Store request in RRD-MA 2.3. rc3
  • Date: Mon, 08 Oct 2007 13:38:47 +0300

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

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




Archive powered by MHonArc 2.6.16.

Top of Page