Ultimately, that's what a container image is. From the outside, its a statically linked binary. From the inside, it can be assembled using modular techniques. The best thing about it, is you can use container scanners and other techniques to gain a lot of the benefits of that modularity still. Plus, you don't need special compilers, whole dependency chains compiled with static options, etc. So an interesting data point in the statically linked binary vs dynamic debate. Its kind of both. ________________________________________ From: Rok Jaklič <rjaklic@xxxxxxxxx> Sent: Wednesday, June 2, 2021 1:18 PM To: Harry G. Coin Cc: ceph-users Subject: Re: Why you might want packages not containers for Ceph deployments Check twice before you click! This email originated from outside PNNL. In this giga, tera byte times all this dependency hell can now be avoided with some static linking. For example, we do use statically linked mysql binaries and it saved us numerous times. https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2F5PmHRSeA2c8%3Ft%3D490&data=04%7C01%7CKevin.Fox%40pnnl.gov%7C9b5e6f33be734b5c0f5008d92603cfc9%7Cd6faa5f90ae240338c0130048a38deeb%7C0%7C0%7C637582621412826966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=XLMvuVzoCaBgq2swTc8x5ehpdCVP5xTRwuwU6XnL%2Fgo%3D&reserved=0 Rok On Wed, Jun 2, 2021 at 9:57 PM Harry G. Coin <hgcoin@xxxxxxxxx> wrote: > > 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 > > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |