----- Original Message -----
> [...]
> > Looks good - warrants a tweak to qa/1067 to regression test it?
>
> Metrics with instances wouldn't work if the style fix would break things
> so I think we're ok in that sense
Oh, I meant for the derived metric config support, not the style fix up.
Such a simple change, maybe its borderline - but it might be good to have
a regression check that if the file name (monster) is in place, and has a
valid (or invalid) content, then good stuff (or appropriate error) happens.
Up to you, its simple stuff - lemme know if you think its worth it; if not
I think we can just push in that pmLoadDerivedConfig patch as-is.
> but qa/1067 may need a bit of other
> kind of tweaking, I'm seeing:
> [...]
> So the results depend on the contents of the
> /var/lib/pcp/pmdas/sample/dynamic.indom file (and that it actually
Aha, this is a failure in the test - it should be controlling that config
file like test qa/535 does (although there are newer test helper APIs now).
> exists, the failure is different it doesn't). Do you think it's
> worthwhile to keep these metrics as part of 1067? If so, how to make the
> test tolerant to missing / different dynamic.indom files?
I've pushed in a fix to use _save_config() and _restore_config() routines,
could you double-check that for me & make a call re above test case?
Thanks Marko.
--
Nathan
|