Error: Adding new Host to ovirt-engine
by Ahmad Khiet
Hi,
Can't add new host to ovirt engine, because the following error:
2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts :
Set facts] *************************************
2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => {
"ansible_facts": {
"ansible_python_interpreter": "/usr/bin/python2",
"host_deploy_vdsm_version": "4.40.0"
},
"changed": false
}
2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver
: Install ovs] *********************************
2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! =>
{}
MSG:
The conditional check 'cluster_switch == "ovs" or (ovn_central is defined
and ovn_central | ipaddr and ovn_engine_cluster_version is
version_compare('4.2', '>='))' failed. The error was: The ipaddr filter
requires python's netaddr be installed on the ansible controller
The error appears to be in
'/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml':
line 3, column 5, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- block:
- name: Install ovs
^ here
2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP
*********************************************************************
2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 :
ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0
ignored=0
whats missing!?
Thanks
--
Ahmad Khiet
Red Hat <https://www.redhat.com/>
akhiet(a)redhat.com
M: +972-54-6225629
<https://red.ht/sig>
1 month, 1 week
Change in DNF COPR plugin requires action
by Marcin Sobczyk
Hi All,
recently there was a PR merged to DNF COPR plugin [1] that makes the
default chroot on CentOS Stream 9 to be 'epel-9'. Because of this we now
need to specify the 'centos-stream-9' chroot name that we use in oVirt
COPR explicitly, i.e.:
dnf copr enable -y ovirt/ovirt-master-snapshot centos-stream-9
I can see there's a bunch of places throughout our projects that need an
update. I'll post PRs for the ones I can spot.
Regards, Marcin
[1]
https://github.com/rpm-software-management/dnf-plugins-core/pull/459/files
1 year
github testing: merge with branch, or use PR HEAD?
by Yedidyah Bar David
Hi all,
I was annoyed for some time now by the fact that when I used some
github-CI-generated RPMs, with a git hash in their names, I could
never find this git hash anywhere - not in my local git repo, nor in
github. Why is it so? Because, if I got it right, the default for
'actions/checkout@v2' is to merge the PR HEAD with the branch HEAD.
See e.g. [1]:
HEAD is now at 7bbb40c9a Merge
026bb9c672bf46786dd6d16f4cbe0ecfa84c531d into
35e217936b5571e9657946b47333a563373047bb
Meaning: my patch was 026bb9c, master was 35e2179, and the generated
RPMs will have 7bbb40c9a, not to be found anywhere else. If you check
the main PR page [3], you can find there '026bb9c', but not
'7bbb40c9a'.
(Even 026bb9c might require some effort, e.g. "didib force-pushed the
add-hook-log-console branch 2 times, most recently from c90e658 to
66ebc88 yesterday". I guess this is the result of github discouraging
force-pushes, in direct opposite of gerrit, which had a notion of
different patchsets for a single change. I already ranted about this
in the past, but that's not the subject of the current message).
This is not just an annoyance, it's a real difference in semantics. In
gerrit/jenkins days, IIRC most/all projects I worked on, ran CI
testing/building on the pushed HEAD, and didn't touch it. Rebase, if
at all, happened either explicitly, or at merge time.
actions/checkout's default, to auto-merge, is probably meant to be
more "careful" - to test what would happen if the code is merged. I
agree this makes sense. But I personally think it's almost always ok
to test on the pushed HEAD and not rebase/merge _implicitely_.
What do you think?
It should be easy to change, using [2]:
- uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.sha }}
No need to reach a complete consensus - can be decided upon
per-project/repo. But if you disagree, I'd like to understand why.
Thanks.
Best regards,
[1] https://github.com/oVirt/vdsm/runs/6881311961?check_suite_focus=true
[2] https://github.com/marketplace/actions/checkout?version=v2.4.2#checkout-p...
[3] https://github.com/oVirt/vdsm/pull/249
--
Didi
1 year, 1 month
Starting with oVirt
by Teemu Saarinen
Hi,
Our company is planning of taking oVirt in into our environment. We would have a few questions for that if you could guide us.
Hardware:
What would be the minimum configuration for us using oVirt?. Idea would be to replace all our current Linux and Windows servers with oVirt. There are currently 24 servers in use.
The goal would also be that the virtual servers could be migrated live and also in the HA configuration, i.e. if one hardware crashes execution continues on the other.
As far as I understand Ovirt enables this?
So we would like to know what kind of hardware (minimum) we should have for this size of environment?
Storagin:
Do all machines need a lot of hard disk space or is it enough to have only one or two? I'm referring to shared storage. Can you also have storagin as HA?
Host:
What happens to HOST1 and HOST2 virtual machines if the oVirt host server crashes?
Do they continue to operate without it, or do they crash at the same time?
Thank You!
Teemu S.
1 year, 1 month
Obsoleting Packages in 'dnf check-update' on RHEL 8.6 hosts
by Scott Worthington
Hello,
My 4.5.1.3-1.el8 oVirt homelab cluster is running on RHEL 8.6 hosts and a
RHEL 8.6 stand-alone engine.
During the installation, I followed the instructions for RHEL 8.6:
https://ovirt.org/download/install_on_rhel.html
After the installation is complete, all packages are up-to-date, and
everything is running, I run a 'dnf check-upgrade' and I find there are
two packages that are listed under "Obsoleting Packages":
"""
Last metadata expiration check: 0:43:06 ago on Mon 01 Aug 2022 08:08:50 AM
EDT.
Obsoleting Packages
centos-stream-release.noarch 8.6-1.el8
@@System
centos-stream-release.noarch 8.6-1.el8
@@System
centos-stream-release.noarch 8.6-1.el8
@@System
redhat-release.x86_64 8.6-0.1.el8
@rhel-8-for-x86_64-baseos-rpms
"""
For the hosts, it makes it appear that the hosts always have an upgrade
pending in the oVirt Engine UI.
"centos-strea-release.noarch" appears to contain similar files to the
original RHEL 8.6 package "redhat-release-8.6.0.1.el8" except for the
addition of "centos*" named files.
Any thoughts on how to change this behavior so that it doesn't appear to
have packages to upgrade because a 'dnf update' does nothing to these
"Obsoleting Packages"?
Thanks in advance.
1 year, 1 month
