----- Original Message ----- > From: "Dan Kenigsberg" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "VDSM Project Development" <[email protected]>, > "engine-devel" <[email protected]>, "users" > <[email protected]> > 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? [email protected], 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 _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
