On 03/29/2015 09:52 PM, Nathan Scott wrote:
> Hi David,
>
> Noticed a couple of little things when we were looking at that install
> failure you saw recently...
>
> # pmParseUnitsStr() doesn't handle unicode
> utf8_units = units.encode("utf-8")
>
> this has been resolved below the API since you encountered this I think,
> so you should be able to safely remove that now and pass native strings
> around directly. Please let me know if not the case, cos there's a bug
> lurking there still then.
I got rid of the utf-8 encoding, and I get the following error (using
"count" as the unit):
PM_ERR_CONV Impossible value or scale conversion count
So, there must be a bug still lurking there.
> Also, the strategy for generating pmids and indom ids ...
>
> self.__pmda.indom_idx += 1
> self.__metric_idx += 1
> self.cluster_idx += 1
>
> ... needs to be deterministic, else bugs - see mail re dmcache/dmthin a
> little earlier for more details. IOW, restarting/reconfiguring the PMDA
> needs to ensure the same IDs are generated for the same metrics/indoms.
I couldn't find the email you were referring to, but I see the problem
with keeping the IDs the same for the same metrics/indoms. I'm not sure
I can think of a good scheme to fix that problem. Do any of the other
PMDAs solve this problem for non-static metrics? We could use a crypto
hash function, but we've only got 22-bits to encode the cluster/item in.
--
David Smith
dsmith@xxxxxxxxxx
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
|