non-redhat version of ovirt-host-deploy

Hi, I'm trying to get ovirt working on Linux From Scratch. So far so good, I can build and install it, and engine-setup also works fine. Now, I'm at the last stage, configuring it. And this is where I hit serious trouble: ovirt-host-deploy requires dnf/yum/rpm. But since I'm not running a redhat-based distro, I have none of those. Short of reading the source code, what are the steps I need to manually perform to get a working host? Thanks, IvanK.

On Tue, Feb 26, 2019 at 2:35 PM <ivan.kabaivanov@gmail.com> wrote:
Hi,
I'm trying to get ovirt working on Linux From Scratch. So far so good, I can build and install it, and engine-setup also works fine. Now, I'm at the last stage, configuring it. And this is where I hit serious trouble: ovirt-host-deploy requires dnf/yum/rpm.
It does not _require_ them. If they are missing, it won't do package management. You can also force it to disable package management by enabling the offline packager, check the README.
But since I'm not running a redhat-based distro, I have none of those.
Short of reading the source code, what are the steps I need to manually perform to get a working host?
There were efforts in 3.5 days to port oVirt to gentoo, and later some efforts to port to Debian. You might want to check about these. You can try checking the dependencies of ovirt-host and make them available somehow (build from source or whatever). You can also check the developer pages on the site, vdsm in particular. And of course, you can simply try and see what happens. I do not think we have documentation on using host-deploy from a dev-env engine without installing from rpm, but you might find notes by previous porters. May I ask what you want to achieve? Personally I think that if I'd wanted to port such a big project to an unsupported OS, I'd start by installing on a supported OS, so that I can compare and check how things should work where they do work. You can do this with nested-kvm, no need for separate hardware. Good luck and best regards, -- Didi

Hey, thanks again for taking the time to answer my questions. I really appreciate it! You are right about first running ovirt in its native distribution (RHEL/Fedora/Centos) so I can familiarize myself with its proper functioning state. Even though I did not mention it, I am doing just that -- I have a CentOS VM with ovirt-engine running and another one with ovirt-node. However, sometimes I still run into issues I am uncertain the root cause of. I will do some more testing and reading of READMEs and the code and check how ovirt works on CentOS. Perhaps I'll start another thread, titled Porting oVirt to LFS where I will post my questions as I run into issues I can't resolve on my own, instead of starting a new thread for each one? One thing I would like to raise now is that various packages or even different scripts within the same package depend on either python2 or python3 and some use the very ambiguous #!/usr/bin/python. Trouble is, I recently switched to python3 by default, so /usr/bin/python is actually python3, not as the script assumes, python2. So I'm patching those to #!/usr/bin/python2. But it would be very useful, now that I read somewhere that Fedora is about to default to python3, to not assume python2 is default and explicitly specify the interpreter #!/usr/bin/env python2 or #!/usr/bin/env python3. Thanks, IvanK.

On Thu, Feb 28, 2019 at 12:06 AM <ivan.kabaivanov@gmail.com> wrote:
Hey, thanks again for taking the time to answer my questions. I really appreciate it!
You are right about first running ovirt in its native distribution (RHEL/Fedora/Centos) so I can familiarize myself with its proper functioning state. Even though I did not mention it, I am doing just that -- I have a CentOS VM with ovirt-engine running and another one with ovirt-node. However, sometimes I still run into issues I am uncertain the root cause of.
I will do some more testing and reading of READMEs and the code and check how ovirt works on CentOS.
Perhaps I'll start another thread, titled Porting oVirt to LFS where I will post my questions as I run into issues I can't resolve on my own, instead of starting a new thread for each one?
I think a thread per issue is much more likely to attract people that know the answer to actually respond... Perhaps add 'Port-To-LFS' in the subject. Perhaps write a series of blog posts about your work, sounds like it will be quite an interesting read :-) Check also all of the developer pages on the site. At least for the engine we have a notion called 'dev env' - where everything runs as non-root and does not rely on anything distribution-specific. This is described in the README, and also: https://www.ovirt.org/develop/developer-guide/engine/engine-development-envi... Obviously there are some differences between this and LFS: 1. In LFS you might actually want to do run things as root and have them manage your env. I guess from LFS's POV this should be optional, for the user to choose :-) 2. You do have to somehow provide all the dependencies. The engine's README does detail them, but it's not easy to actually provide them if not using a supported distro. Since you said you already have a working engine inside LFS, I guess you are now past this point anyway. Also, it's not fully clear what you want to achieve on the hosts side. Do you want them to be fully-LFS too? Do you then also want the engine to do package management (e.g. upgrades) on them? You'll have to first clearly define what you want to do.
One thing I would like to raise now is that various packages or even different scripts within the same package depend on either python2 or python3 and some use the very ambiguous #!/usr/bin/python. Trouble is, I recently switched to python3 by default, so /usr/bin/python is actually python3, not as the script assumes, python2. So I'm patching those to #!/usr/bin/python2. But it would be very useful, now that I read somewhere that Fedora is about to default to python3, to not assume python2 is default and explicitly specify the interpreter #!/usr/bin/env python2 or #!/usr/bin/env python3.
Python3 support is work in progress. Some parts already ported, others not yet. The biggest part IIUC is vdsm, and you might want to check a recent thread on the devel list "[ovirt-devel] Running Vdsm on Python 3". Thanks, good luck and best regards,
Thanks, IvanK. _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/KJOLZA2KVU3QHK...
-- Didi
participants (2)
-
ivan.kabaivanov@gmail.com
-
Yedidyah Bar David