Hi,
On 2015-12-14 07:08, Nathan Scott wrote:
> ----- Original Message -----
>> [...]
>
>> One could rework pmcc to use pmfg perhaps. Or leave it alone as a
>> legacy API.
>
> pmcc is not just a fetchgroup-alike API, it does a number of other very
> useful things too, abstracting code out from high level python scripts.
what do we actually mean by pmcc? Just pmcc.py or pmcc.py+pmsubsys.py
and something else as well? If just pmcc.py then it doesn't look very
interesting after seeing pmfg.
> These things are needed still and always will be (see -T pmrep bug from
> earlier mail).
A generic method to figure out samples/interval/runtime to apply as
pmrep does would be helpful. But that's still pretty easy to write
compared things like figuring out the right mode for pmSetMode() by with
the help SECS_IN_24_DAYS and PM_XTB_SET etc:
http://oss.sgi.com/pipermail/pcp/2015-November/008742.html
> Updating pmcc to use pmfg should be useful on several levels - as you say,
> Mark; it should cause a reduction of code in pcp.pmcc, and we need to have
> a coherent plan going forward - otherwise we might see a last-minute series
> of patches a couple of days before release, where folk try to second guess
> the appropriate future API to use (*cough*).
>
> So, we need to see a resolution to this - either as a "pmfg+pmcc" API or a
> "pmfg+new-high-level-API" (if pmcc/pmfg cannot be tweaked to work together
> & in that case, we need to see that new API, and understand why its needed
> over pmcc) before any core libpcp fetchgroup addition is added - this lack
> of cohesion is already causing confusion. There's plenty of time; hmmm,
> except that we are keen to start abstracting a bunch of code from pmrep to
> ..somewhere (pmcc?) soon, so the sooner the better I guess.
For the record, I don't much like pmcc.py, it's confusing and limited
compared to pmfg (and the complete lack of documentation certainly
doesn't help). We should definitely keep the plain pmfg as an
alternative to users even if we'd marry pmfg+pmcc. Users can then choose
either one depending on their application / needs.
Thanks,
--
Marko Myllynen
|