[ovirt-users] [Pkg-libvirt-discuss] Fwd: Building ovirt-host-deploy gives `configure: error: otopi-devtools required but missing`

Fri May 19 07:36:27 UTC 2017

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 at ovirt.org>
> 
> ---------- Forwarded message ----------
> From: Yedidyah Bar David <didi at 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 <lenikmutungi at gmail.com>
> Cc: Jason Brooks <jbrooks at redhat.com>, users <users at ovirt.org>
> 
> On Mon, May 15, 2017 at 10:42 PM, Leni Kadali Mutungi
> <lenikmutungi at gmail.com> wrote:
> > On 5/15/17, Yedidyah Bar David <didi at 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-java at 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 <bkorren at 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 <didi at redhat.com>
> Cc: Leni Kadali Mutungi <lenikmutungi at gmail.com>, users <users at ovirt.org>
> 
> On 16 May 2017 at 09:51, Yedidyah Bar David <didi at 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