On 06/22/2015 05:09 PM, Nathan Scott wrote:
Hi Mark,
----- Original Message -----
Changes committed to git://git.pcp.io/markgw/pcp/pcp.git master
Looks good - I fixed a few typos, but nothing of interest. Handful
of other small things worth considering...
thanks for the RV
- the Makepkgs --with-containers option maybe should be --with-docker
since its not useful for other container runtimes
the intent was that eventually lxc would also be supported, hence the
agnostic name. But I'll change it to --with-docker for now (and potentially
change it again if and when we support other container management
systems). There is a systemd variant brewing in this space too, see
https://wiki.archlinux.org/index.php/Systemd-nspawn
- that option should be propagated through to configure, so that it
can verify all the necessary build toolchain is present - especially
the docker and dnf binaries that it needs (that version checking you
have in Makepkgs traditionally would live in configure.ac).
yes agree, and we'd use $HAVE_DOCKER or whatever throughout the build.
So I'll work on making that change.
- the qa/admin/check-vm script should be updated for these tools and
their respective package names
ok
- 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. What advantage would there
be in having a pcp-libs container?
I guess so, for people writing C monitoring tools in containers (need
libpcp), and/or instrumented applications (may need libpcp_mmv, etc)
in containers.
well they'd be better off layering over pcp-monitor wouldn't they?
Or do we want to try and keep container hierarchies nice and flat?
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
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. Or is this overkill? pid-1 in pcp-data would
just pmpause I guess.
there are too many possibilities here ... Thoughts?
|