----- Original Message -----
> >
> > Log file naming conventions - one of the issues with the current
> > scheme is that a host can end up with many, many archives in one
> > directory [...]
>
> The current code does a log-merge of all previous archives into one,
> doing data-aging at the same time, so thar particular type of trash
> doesn't pile up.
/me re-reads the code ... I'm not following what you mean by "doing
data-aging"? Having a single archive for many days/months would be
unsustainable (in terms of its in-core size) without *some* form of
temporal data reduction, but we don't have code to do that (or have
I missed that code? or did you mean its still coming / planned?).
There is a pmlogreduce(1) tool - but its not used by pmmgr AFAICS.
I also am not sure what state its in, but last I chatted to Ken about
that, he suggested work remains (several TODO items exist in the code,
I don't know how severe they are though - Ken? - it does have good QA
test coverage going for it).
Anyway, some people will not want to data reduce and will want to keep
their original high precision data ... the YYYY/MM/DD scheme is still
going to help those folks to navigate their archives (I'm assuming a
single archive for high precision data over months/years is not really
feasible with the current archive format - but maybe thats something
we could tackle instead). wrt lots of archives - from memory, it was
the pmchart "Add Archive" window that caused problems, with hundreds/
thousands of archives in one directory - becomes very user-unfriendly.
> > Log rewriting (pmlogrewrite) seems to be missing? (nor in the todo)
>
> Will add to the TODO. Is that urgent?
Not if we're comfortable with the side-by-side approach going forward
(which is fine with me too). I think getting the new code into peoples
hands to try out sooner rather than later will be most useful at this
stage - and with the two side-by-side we can polish the new approach as
we go.
If we're attempting log merging to the level I later realised you may
be doing (one archive to rule them all), it quickly becomes a pressing
need as merging is impossible without it (when PMDA evolution occurs,
as described in pmlogrewrite(1) para #2).
> > [packaging]
> >
> > What's the plan? If we want to allow people to pick and choose between
> > cron-based and pmmgr-based (which I imagine we do) we need to split both
> > styles into separate rpms which replace/conflict with each other, I think?
>
> They don't need to conflict in any mechanical sense, and they run fine
> (unaware of each other) side-by-side.
OK, yep, sounds fine.
> Yes, that's a possible way to segregate the might-be-deprecated-eventually
> files, if it became urgent.
> ...
Its certainly not urgent at this stage, just wanted to mention it so that
we've thought about it & are happy with which ever approach we choose now.
cheers.
--
Nathan
|