On Fri, May 19, 2017 at 06:28:36AM +0300, Leni Kadali Mutungi wrote: > I'd like the input of the Debian Virtualization Team on the messages > below. When replying, cc the oVirt team <users@ovirt.org> > > ---------- Forwarded message ---------- > From: Yedidyah Bar David <d...@redhat.com> > Date: Tue, 16 May 2017 09:51:24 +0300 > Subject: Re: [ovirt-users] Building ovirt-host-deploy gives > `configure: error: otopi-devtools required but missing` > To: Leni Kadali Mutungi <lenikmutu...@gmail.com> > Cc: Jason Brooks <jbro...@redhat.com>, users <users@ovirt.org> > > On Mon, May 15, 2017 at 10:42 PM, Leni Kadali Mutungi > <lenikmutu...@gmail.com> wrote: > > On 5/15/17, Yedidyah Bar David <d...@redhat.com> wrote: > > > >> Now is the time to explain something. > >> > >> ovirt-host-deploy is not designed to be ran manually like you try. > >> > >> You will get the exact same error if you try to do this on CentOS or > >> Fedora. > >> > >> The normal way it works is that the engine "bundles" it in a tarball, > >> copies it to the target host using ssh, untars it there and runs it. > >> > >> It then talks with it - the engine sends some stuff, host-deploy replies, > >> etc. > >> > > I'm guessing this means I can now move on to building ovirt-engine.
When looking into packaging the Java dependencies talk to the Debian Java packaging team: debian-j...@lists.debian.org > > That would be great, but: > > 1. It will require a lot of work, mostly probably of packaging in Debian > dependencies of the engine that are not yet there. > > 2. You'll be mostly walking the unwalked path. Most of the work on Debian > support so far was on the hosts' side. > > Re (1.), you should also note that currently, the engine is not even > packaged properly for Fedora/CentOS. I know this sounds weird, as everyone > uses the packages we provide, but it's true - these packages are not > compliant with Fedora's packaging guidelines. Why? Because we use maven > for building the engine, and package also many dependencies simply as > a result of maven getting them from maven central. See also: > > https://bugzilla.redhat.com/showdependencytree.cgi?id=1168605&hide_resolved=0 > > Best, > > > > >> The protocol they use is described in otopi, in the file README.dialog. > >> > >> otopi has (currently) two "dialects" - "human" (default) and "machine". > >> The engine and ovirt-host-deploy talk using the machine dialog. > >> > >> To make ovirt-host-deploy talk with you using the machine dialog, > >> you should run it with: > >> > >> ovirt-host-deploy DIALOG/dialect=str:machine > >> > >> To make it let you configure it, run it with: > >> > >> ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True > >> > >> To know what it expects at each stage, I suggest to have a look at an > >> ovirt-host-deploy log generated on el7 or fedora. > >> > > This is very useful; will definitely try this out. > >> Anyway, congrats for a nice progress! > > Thanks. I wouldn't have come this far without the community's help and > > the documentation. > > > >>> I tried starting the libvirtd service to see if that would make the > >>> VIRT/enable error go away or at least satisfy the requirements of > >>> ovirt-host-deploy, but it didn't seem to work. > >> > >> If you check such a log file, you'll see there (among other things): > >> > >> DIALOG:SEND **%QStart: CUSTOMIZATION_COMMAND > >> DIALOG:SEND ### > >> DIALOG:SEND ### Customization phase, use 'install' to proceed > >> DIALOG:SEND ### COMMAND> > >> DIALOG:SEND **%QHidden: FALSE > >> DIALOG:SEND ***Q:STRING CUSTOMIZATION_COMMAND > >> DIALOG:SEND **%QEnd: CUSTOMIZATION_COMMAND > >> DIALOG:RECEIVE env-query -k VIRT/enable > >> DIALOG:SEND **%QStart: VIRT/enable > >> DIALOG:SEND ### > >> DIALOG:SEND ### Please specify value for 'VIRT/enable': > >> DIALOG:SEND ### Response is VALUE VIRT/enable=type:value or > >> ABORT VIRT/enable > >> DIALOG:SEND ***Q:VALUE VIRT/enable > >> DIALOG:SEND **%QEnd: VIRT/enable > >> DIALOG:RECEIVE VALUE VIRT/enable=bool:true > >> > >> "SEND" is what the host-deploy sends, "RECEIVE" is what the engine > >> replies. > >> > >> So host-deploy sent a prompt asking for a customization command, > >> the engine sent the command 'env-query -k VIRT/enable', host-deploy > >> then asked the engine to provide a value for 'VIRT/enable', and the > >> engine replied 'VIRT/enable=bool:true'. > >> > > Okay. Will try to look into this as well. > > > >>> The other errors seem > >>> to be related to not having an IP address that ovirt-host-deploy can > >>> recognize. To package this for Debian, I would need to find the > >>> equivalent of yumpackager.py for aptitude/apt-get/apt, since it seems > >>> to be a dependency required by ovirt-host-deploy. > >> > >> As I said, you can ignore it for now. But IMO this isn't specific > >> to Debian - search a bit and you'll find other similar cases. > > Alright. Good to know. :) > > > >> > >>> > >>> TL;DR: How to enable the virt service and assign an IP address that > >>> ovirt-host-deploy can use. > >>> Write/Find a python script that is equivalent to yumpackager.py and > >>> miniyum.py so that that dependency for ovirt-host-deploy is satisfied > >>> as well. > >> > >> Last one will indeed be very interesting, but isn't mandatory for you > >> to continue, if your stated goal is to have a Debian host managed by > >> an oVirt engine. You can manually install all your stuff on the host, > >> and use offlinepackager so that host-deploy will not try to install > >> stuff for you. You'll then have a harder first-time-install, and > >> will miss checking for updates etc. For these you'll indeed need to > >> write something like debpackager, and probably minideb as well - > >> engine-setup uses it directly, as otopi's packager isn't enough for it. > >> > >> I'd like to mention another point. As explained above, when the engine > >> adds a host, it copies to it a bundle (tarfile). This bundle is not > >> rpm/yum/dnf specific - it should work also on Debian. Normally, > >> ovirt-host-deploy (the rpm package) is installed only on the engine > >> machine. So if you do not care about the engine side for now, you > >> should be able to try adding a Debian host to your engine already - > >> just configure offline packager. This might be easier to debug then > >> by manually running ovirt-host-deploy. > > Well, my aim is to run oVirt *on* Debian, similar to how it is run and > > used by users on say Fedora or RHEL/CentOS. So that's what is guiding > > me. If your suggestions need to revised in the light of that, do let > > me know. > > > > - Warm regards > > Leni Kadali Mutungi > > > > -- > Didi > > > ---------- Forwarded message ---------- > From: Barak Korren <bkor...@redhat.com> > Date: Tue, 16 May 2017 10:06:58 +0300 > Subject: Re: [ovirt-users] Building ovirt-host-deploy gives > `configure: error: otopi-devtools required but missing` > To: Yedidyah Bar David <d...@redhat.com> > Cc: Leni Kadali Mutungi <lenikmutu...@gmail.com>, users <users@ovirt.org> > > On 16 May 2017 at 09:51, Yedidyah Bar David <d...@redhat.com> wrote: > > > > Re (1.), you should also note that currently, the engine is not even > > packaged properly for Fedora/CentOS. I know this sounds weird, as everyone > > uses the packages we provide, but it's true - these packages are not > > compliant with Fedora's packaging guidelines. Why? Because we use maven > > for building the engine, and package also many dependencies simply as > > a result of maven getting them from maven central. See also: > > > > https://bugzilla.redhat.com/showdependencytree.cgi?id=1168605&hide_resolved=0 > > > > I guess we could walk the middle ground here for DEBs just like we do > for RMPs no? Which means - have java dependency bundle packages and > release from resources.ovirt.org... > > I would love to see a discussion on what it would take to get DEBs > through the CI system. I guess we would need some sort of > 'build-artifacts.sh.deb' (Or deb8? dep9? not sure what is the > convention for Debian version shorthands), some Debian build slaves > and Debian equivalents of mock_runner.sh and repoan. The Foreman project has nice out of tree packages: http://deb.theforeman.org/ that are built via a CI system so having a look at their setup might make sense. If you're using jenkins for CI the jenkins-debian-glue package might be worth a look. Cheers, -- Guido _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users