On 6/2/21 2:28 PM, Phil Regnauld wrote:
Dave Hall (kdhall) writes:
But the developers aren't out in the field
with their deployments
when something weird impacts a cluster and the standard approaches don't
resolve it. And let's face it: Ceph is a marvelously robust solution for
large scale storage, but it is also an amazingly intricate matrix of
layered interdependent processes, and you haven't got all of the bugs
worked out yet.
I think you hit a very important point here: the concern with
containerized deployments is that they may be a barrier to
efficient troubleshooting and bug reporting by traditional methods
(strace et al) -- unless a well documented debugging and analysis
toolset/methodolgy is provided.
Paradoxically, containerized deployments certainly sound like they'd
free up lots of cycles from the developer side of things (no more
building packages for N distributions as was pointed out, easier
upgrade and regression testing), but it might make it more difficult
initially for the community to contribute (well, at least for us
dinosaurs that aren't born with docker brains).
Cheers,
Phil
I think there's great value in ceph devs doing QA and testing docker
images, releasing them as a 'known good thing'. Why? Doing that avoids
dependency hell inducing fragility-- fragility which I've experienced in
other multi-host / multi-master packages. Wherein one distro's
maintainer decides some new rev ought be pushed out as 'security update'
while another distro's maintainer decides it's a feature change, another
calls it a backport, etc. There's no way to QA 'upgrades' across so
many grains of shifting sand.
While the devs and the rest of the bleeding-edge folks should enjoy the
benefits that come with tolerating and managing dependency hell, having
the orchestrator upgrade in a known good sequence from a known base to a
known release reduces fragility.
Thanks for ceph!
Harry