[Users] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)

[Dan Kenigsberg]

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?  users at ovirt.org, 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?

> > > > > 
> > > > >  * 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)

> 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.

> If we want to automatically enable dumps I guess it should go to /var/lib/core or similar.