On Fri, Sep 07, 2018 at 10:46:01AM +0530, Pranith Kumar Karampuri wrote: > On Tue, Sep 4, 2018 at 6:06 PM Dave Sherohman <dave@xxxxxxxxxxxxx> wrote: > > > On Tue, Sep 04, 2018 at 05:32:53AM -0500, Dave Sherohman wrote: > > > Is there anything I can do to kick the self-heal back into action and > > > get those final 59 entries cleaned up? > > > > In response to the request about what version of gluster I'm running > > (...which I deleted prematurely...), it's the latest version from the > > Debian stable repository, which they identify as 3.8.8-1. > > > > Hey, 3.8.8-1 is EOL, is it possible to use upstream version that is > maintained like 3.12.x or 4.1.x? I prefer to stick with the Debian stable releases because they are **STABLE**. Backported fixes for security issues, and that's it. No new features to introduce new bugs, no incremental changes that just happen to break backwards compatibility in the process. We currently are using an upstream elasticsearch because of an application which requires features that aren't in deb-stable. As part of the same server move that led to my question here, we also had our elasticsearch cluster go down because, when the servers rebooted, a version incompatibility with one of the es plugins prevented it from starting back up. I don't want that happening with our disks. I want something that I know works today and will continue to work tomorrow, even if a security patch comes out between now and then. If gluster upstream has a "security fixes and critical bugfixes ONLY, never a single new feature" version available, then point me at it and I'd be comfortable switching to that, but if it's the usual "Security fix? Just upgrade to the latest and greatest new version!", then I'd really rather not. That model works (more or less...) for end-user software, but I don't want it anywhere near my servers. -- Dave Sherohman _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users
