[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 4:41:04 PM
> Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
> 
> 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.

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

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

> 
> > 
> >  * legacy-removed: kernel version test, package dependency is
> >  sufficient.
> > 
> >  * legacy-removed: do not add kernel parameter
> >  processor.max_cstate=1
> >    warn if not have constant_tsc
> >    https://bugzilla.redhat.com/show_bug.cgi?id=770153
> > 
> >  * legacy-change: io elevator scheduler set in kernel command-line
> >    use either udev rule in vdsm package or tuned.
> > 
> >  * legacy-change: vdsm libvirt reconfigure
> >    vdsm is reconfigured with file based trigger instead unsupported
> >    systemd
> >    init.d parameter.
> > 
> >  * legacy-change: distribution checks are simpler based on Python
> >  platform,
> >    minimum:
> >    - rhel-6.2
> >    - fedora-17
> > 
> >  * legacy-change: minimum vdsm version is taken from engine not
> >  hard coded.
> > 
> >  * legacy-change: pki is now using m2crypto to generate certificate
> >  request
> >    and parse certificates.
> > 
> >  * legacy-change: use iproute2 instead of python ethtool to avoid
> >  another
> >    dependency for host name validation.
> > 
> >  * legacy-change: use iproute2 instead of reading /proc/net/route
> >  for route
> >    information and interface information.
> > 
> >  * legacy-change: do not use vdsm.netinfo for vlan and bonding as
> >  it requires
> >    /usr/share/vdsm modules, and it is trivial anyway.
> > 
> >  * legacy-change: use vdsm-store-net-config script to commit
> >  network config
> >    instead of internal duplicate implementation.
> > 
> >  * legacy-change: /etc/vdsm/vdsm.conf is overridden unless
> >  VDSM/configOverride
> >    environment is set to True
> 
> I'm a bit confused by the negation: I'd expect
> VDSM/configOverride=True
> to mean "override /etc/vdsm/vdsm.conf".

Sorry!
It should be False.

> 
> > 
> >  * legacy-change: /etc/vdsm/vdsm.conf is not read of fake_qemu.
> >    set VDSM/checkVirtHardware environment to False to avoid
> >    hardware detection.
> > 
> >  * legacy-change: following gluster packages not installed:
> >    - glusterfs-rdma
> >    - glusterfs-geo-replication
> 
> 
> 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.

Alon.