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