----- Original Message -----
From: "Dan Kenigsberg" danken@redhat.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "engine-devel" engine-devel@ovirt.org, "users" users@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@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:
- host install
- ovirt-node install
- 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