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(a)ovirt.org, please chime in!
>
> >
> > 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`.
>
> > * 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?
>
>
> 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? ;-)