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

[Alon Bar-Lev]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> <users at ovirt.org>
> Sent: Wednesday, November 28, 2012 9:48:41 PM
> Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> 
> On Wed, Nov 28, 2012 at 09:45:17AM -0500, Alon Bar-Lev wrote:
> > 
> > > On Wed, Nov 28, 2012 at 08:59:10AM -0500, Alon Bar-Lev wrote:
> > > > Hello All,
> > > > 
> > > > Preparing to ovirt-engine 3.2 the entire "vdsm-bootstrap"
> > > > bootstrap
> > > > was re-written from scratch into more pluggable and flexible
> > > > implementation, available at git master and nightly snapshots.
> > > > 
> > > > As far as packaging is concerned there are now two more
> > > > dependencies to ovirt-engine:
> > > > 
> > > >  * otopi -- oVirt Task Oriented Pluggable
> > > >  Installer/Implementation
> > > >  * ovirt-host-deploy -- oVirt host deploy tool
> > > > 
> > > > These packages replace the legacy vdsm-bootstrap package that
> > > > was
> > > > distributed with vdsm.
> > > 
> > > Hurray!
> > > 
> > > I suspect that a `git-rm vds_bootstrap/*` is pending?
> > 
> > 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.

> > 
> > > 
> > > > 
> > > > Git repositories are available at at[1][2].
> > > > Documentation is available at Git repositories - README*.
> > > > Builds are available at usual place[3].
> > > > Bugzilla components will be available shortly.
> > > 
> > > Are there requests to add the components to Fedora (18, EPEL6)?
> > > I think we should add these requests as blockers for Bug 881006 -
> > > Tracker: oVirt 3.2 release.
> > 
> > Yes, I am on this one.
> > 
> > > 
> > > > Change log is attached.
> > > > 
> > > > There is no change in the way the engine is performing the host
> > > > deployment process in term of user experience, other than event
> > > > log
> > > > messages during deployment were improved.
> > > > 
> > > > The log of the deployment is fetched from host and stored at
> > > > engine
> > > > machine at /var/log/ovirt-engine/host-deploy, on host it is at
> > > > /tmp/ovirt-host-deploy*.log and deleted when fetched to engine.
> > > > 
> > > > Among other features, the ovir-host-deploy package can be
> > > > installed
> > > > manually on host and executed to prepare host for installation,
> > > > in
> > > > future we may be able to add host to engine without performing
> > > > the
> > > > deployment process, for now it will be usable for integration
> > > > tests.
> > > > 
> > > > The internals are completely different, instead of having 3
> > > > different
> > > > bootstrap sequences:
> > > >  1. host install
> > > >  2. ovirt-node install
> > > >  3. ovirt-node approve
> > > > 
> > > > We now have single sequence which is common to host and node
> > > > installation or re-installation, end result is much simpler
> > > > implementation.
> > > > 
> > > > Please report any issues even minor issues, so we can stabilize
> > > > it
> > > > for
> > > > 3.2 release.
> > > > 
> > > > Best Regards,
> > > > Alon Bar-Lev.
> > > > 
> > > > [1] http://gerrit.ovirt.org/gitweb?p=otopi.git;a=tree
> > > > [2]
> > > > http://gerrit.ovirt.org/gitweb?p=ovirt-host-deploy.git;a=tree
> > > > [3] http://www.ovirt.org/releases/nightly/rpm/Fedora/17/noarch/
> > > > 
> > > > ---
> > > > 
> > > > Change Log
> > > > 
> > > >  * offline packager feature.
> > > > 
> > > >  * tuned is installed with virtual-host profile.
> > > 
> > > I never understood why this is an installer step, and not part of
> > > vdsmd
> > > start up
> > 
> > There may be several method to tune a machine.
> > Why VDSM should depend on specific one?
> 
> Maybe because I tend to install vdsm using `yum`, and would like it
> to
> do The Right Thing to make the host an oVirt node. I suspect that if
> ovirt-host-deploy
> proves to be easy to use, I could follow my `yum install vdsm` with
> `ovirt-host-deploy`.

I will be glad if you try it out.

> 
> > 
> > > 
> > > >  * initial implementation based on otpoi.
> > > > 
> > > >  * implementation is based on legacy vdsm-bootstrap pacakge
> > > >  functionality.
> > > > 
> > > >  * legacy-removed: legacy VDSM (<3.0) config upgrade.
> > > > 
> > > >  * 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 sysadmin manually enables dumps, he may do this at a location of his own choice.
If we want to automatically enable dumps I guess it should go to /var/lib/core or similar.

> 
> > > 
> > > 
> > > Alon, thanks for your tremendous work on this. I cannot wait to
> > > have
> > > it
> > > up and running in the release.
> > 
> > Thank you!
> > I truly hope that from this point we can only make it better.
> 
> Do you mean that we've reached rock bottom? ;-)

No, that now I have some infrastructure that I can use to provide solutions.

Regards,
Alon