We're trying to come up with a way to deploy OVN provider's firewalld
services during engine setup. The naive solution of querying the user
during customization and then installing during STAGE_PACKAGES fails as
firewalld configuration happens prior to it.
We thought of a couple of possible solutions we'd like your opinions on
(ordered in perceived level of difficulty):
1) Ship/require the packages with ovirt-engine without requiring user
input. This essentially couples engine with OVN and disregards a future
where OVN doesn't run alongside Engine.
2) Install the packages immediately following user input during
customization. A bit hacky and doesn't conceptually fit the stage of
3) Move user input to STAGE_INTERNAL_PACKAGES. Feels more disruptive than
#1 to the current otopi flow as STAGE_INTERNAL_PACKAGES is dedicated for
packages that are required for otopi itself to operate. Not only this
doesn't fit conceptually, it introduces user input to a stage that
shouldn't have any.
4) Move firewalld configuration to happen after STAGE_PACKAGES.
5) Refactor to prepare the grounds for OVN/Engine separation. At this point
this feels very ambiguous. We don't yet know how will containers be
accessed (is ssh guaranteed?) in the future or generally how should a
remote installation look like.
Any input/questions are appreciated.
The Infra team is working on customizing the look of Gerrit to make it fit
better with other oVirt services. I want to share the result of this
effort. Hopefully we can gather some feedback before applying the design to
oVirt's instance of Gerrit.
Please visit the Staging instance to check it out:
The new design is inspired by oVirt's main website. There is a known glitch
that the "Loading Gerrit Code Review" message is overlapped by the logo
when the UI is loading. If you spot any other issues or have ideas for
improvement feel free to respond to this thread or share your feedback in
the following JIRA ticket:
Thanks to Eldan, we have a community ad for oVirt proposed on Stack
Now, we need some upvotes (current threshold is 6) before SO starts serving
Have a SO account?
Want to help?
Just drop by and upvote.
Have a great weekend,
moVirt 2.0 has just been released and should arrive to your devices soon!
You can also get the apk from our GitHub .
The main feature of this release is managing multiple oVirt installations +
many other cool features .
Thanks everybody who helped with testing and especially big thanks to Shira
who gave us lots of valuable input.
Have a nice day
I am kindly asking for help with understanding the origin of conflict
within the *libvirt-guests*.service and *vdsmd.service*.
I am working on a graceful VM shutdown as described by the feature in a
One way (the simplest one as described in the Bugzilla) of achieving the
required functionality is to utilize *"libvirt-guests.service"*, which does
exactly what is required. The second option is to write a new service that
does the shutdown and utilizes the *vdsm.* Since I am new, I do not know
what is the best solution.
Staying with the fist one I have discovered an old conflict between
*and *"libvirt-guests.service"* explained in bug
<https://bugzilla.redhat.com/show_bug.cgi?id=720359> I have tried to
reproduce described scenario and found that it is no longer an issue.
Therefore I have created a *proposal draft* patch to start a discussion,
whether it is really needed or not.
Further, the research in git history showed this conflict precedes the git
history, effectively blocking me in understanding details.
Does somebody know about this issue? I am grateful for any information that
can point me in the right direction.
Thank you in advance for any help.
just an heads up ovirt-system-test is failing on master for:
[ ERROR ] Failed to execute stage 'Environment customization':
requires openstack-java-keystone-model >= 3.1.2',
requires openstack-java-client >= 3.1.2',
requires openstack-java-glance-model >= 3.1.2',
requires openstack-java-glance-client >= 3.1.2',
requires openstack-java-resteasy-connector >= 3.1.2',
requires openstack-java-cinder-client >= 3.1.2',
requires openstack-java-quantum-model >= 3.1.2',
requires openstack-java-keystone-client >= 3.1.2',
requires openstack-java-quantum-client >= 3.1.2',
requires openstack-java-cinder-model >= 3.1.2']
after I merged https://gerrit.ovirt.org/#/c/78761/
Issue is that ovirt-system-test is using CentOS Virt SIG 4.0 repo
instead of 4.2 repo as lookaside repo.
Fixing patch is https://gerrit.ovirt.org/78248 ; I'm trying to get it
merged since June 16th with no luck on Jenkins validation.
If https://gerrit.ovirt.org/78248 won't be merged today please don't
revert https://gerrit.ovirt.org/#/c/78761 but fix the root cause of
eventual failures or we'll continue testing stuff having a test
successful but wrong stuff tested.
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
Do we have or follow a standard on patch granularity? When I started, I
picked up on the culture that we do small, logical commits -- as much as
possible, each commit should be focused on a specific purpose. I've
perceived some reviewers prefer to have all orthogonal changes (fix a
random spelling error, remove a duplicate semicolon) extracted to other
patches for clarity. Others don't seem to mind. I feel like I always want
to ask, but I feel bad because it's a hassle.
Also, when you are asked to extract something, do you have a trick to make
it as easy as possible?
Greg Sheremeta, MBA
Sr. Software Engineer
Red Hat, Inc.