* Alon Bar-Lev <[email protected]> [2012-11-28 14:47]: > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <[email protected]> > > To: "Alon Bar-Lev" <[email protected]> > > Cc: "VDSM Project Development" <[email protected]>, > > "engine-devel" <[email protected]>, "users" > > <[email protected]> > > Sent: Wednesday, November 28, 2012 10:39:42 PM > > Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2) > > > > On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote: > > > > > > > > No... we need it as compatibility with older engines... > > > > > We keep minimum changes there for legacy, until end-of-life. > > > > > > > > Is there an EoL statement for oVirt-3.1? > > > > We can make sure that oVirt-3.2's vdsm installs properly with > > > > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be > > > > upgraded > > > > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh > > > > to > > > > our > > > > vast install base? [email protected], please chime in! > > > > > > > > > > I tried to find such, but the more I dig I find that we need to > > > support old legacy. > > > > Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an > > unupgradable F16). Should we be any better than our (currently > > single) > > platform? > > We should start and detach from specific distro procedures. > > > > > > > > > > > > > > > > > * legacy-removed: change machine width core file > > > > > > > # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern > > > > > > > > > > > > Yeah, qemu-kvm and libvirtd are much more stable than in the > > > > > > old > > > > > > days, > > > > > > but wouldn't we want to keep a means to collect the corpses > > > > > > of > > > > > > dead > > > > > > processes from hypervisors? It has helped us nail down nasty > > > > > > bugs, > > > > > > even > > > > > > in Python. > > > > > > > > > > It does not mean it should be at /var/lib/vdsm ... :) > > > > > > > > I don't get the joke :-(. If you mind the location, we can think > > > > of > > > > somewhere else to put the core dumps. Would it be hard to > > > > reinstate a > > > > parallel feature in otopi? > > > > > > I usually do not make any jokes... > > > A global system setting should not go into package specific > > > location. > > > Usually core dumps are off by default, I like this approach as > > > unattended system may fast consume all disk space because of > > > dumps. > > > > If a host fills up with dumps so quickly, it's a sign that it should > > not > > be used for production, and that someone should look into the cores. > > (P.S. we have a logrotate rule for them in vdsm) > > There should be a vdsm-debug-aids (or similar) to perform such changes. > Again, I don't think vdsm should (by default) modify any system width > parameter such as this. > But I will happy to hear more views. > > > > > > If sysadmin manually enables dumps, he may do this at a location of > > > his own choice. > > > > Note that we've just swapped hats: you're arguing for letting a local > > admin log in and mess with system configuration, and I'm for keeping > > a > > centralized feature for storing and collecting core dumps. > > As problems like crashes are investigated per case and reproduction scenario. > But again, I may be wrong and we should have VDSM API command to > start/stop storing dumps and manage this via its master...
I very much like this idea. There was a thread a while back discussing[1] the this very idea; I was looking for a way to enable 'debugging' mode as well as a way to programatically collect debugging info (which could include host stats, guest stats, logs and any core files). Certainly in such a scenario, being able to enable/disable varous features of a debugging mode could include whether to enable core dumps as well as where to save them on the host. 1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387 -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx [email protected] _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
