Hi Mark,
----- Original Message -----
> >
> > - do we need a pcp-libs container layer between pcp-conf and friends?
>
> I'm inclined to think pcp-libs should be in pcp-base along with pcp-conf
> since both are needed by all other containers.
Yep, I agree that makes sense after looking at pcp-base again.
> Also, whilst we're discussing it - I've been thinking of changing the
> naming a bit, to make it super obvious what each container does, e.g.
>
> pcp-base : base container for layering all other pcp containers
>
> pcp-live-collector - live host pmcd, layered over pcp-base
>
> pcp-archive-collector - archive collection, using pmlogger connected
> to pcp-live-collector on the same or a different host. It could
> instead just use local context pmlogger when that feature has matured.
> There could be a pmmgr variant too, perhaps for logger farms.
>
> pcp-monitor - monitoring tools, including gui and py deps. Such tools
> can also be run remotely of course.
>
> pcp-pmie or some such name ... for inference and alerting tasks
I suggest basically the same, but slighter simpler names :-
- pcp-base (pcp-conf + pcp-libs rpms)
- pcp-collector (pmcd & default pmdas)
- pcp-pmlogger (I'm really not a fan of naming client tools like pmlogger
as "collector" - quickly gets confusing with the way we
use the term throughout the books, man pages, etc)
- pcp-monitor (just as you have, above)
- pcp-pmie (likewise)
> We could also consider a pcp-data container or something, where PCP
> archives and var/lib data such as pmdaCache and so forth would
> reside and be commonly shared, rather than polluting the host with
> assorted bind-mounts.
Sounds to me like it'd be worth experimenting with this, yes.
cheers.
--
Nathan
|