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