OVN provider's firewalld services deployment during engine setup
by Leon Goldberg
Hey,
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
customization.
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.
Thanks,
Leon
7 years, 3 months
New design for the Gerrit UI
by Evgheni Dereveanchin
Hi everyone,
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:
https://gerrit-staging.phx.ovirt.org/
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:
https://ovirt-jira.atlassian.net/browse/OVIRT-912
--
Regards,
Evgheni Dereveanchin
7 years, 3 months
Vdsm dependency on GlusterFS 3.10
by Milan Zamazal
Vdsm master depends on GlusterFS 3.10 now but that doesn't seem to be
available in common RHEL repos. So what's the recommended way to
satisfy the dependency on RHEL hosts?
Thanks,
Milan
7 years, 5 months
Help understanding the conflict with libvirt-guests.service - gerrit patch 78693
by Petr Kotas
Hi,
I am kindly asking for help with understanding the origin of conflict
within the *libvirt-guests*.service and *vdsmd.service*.
Explanation:
I am working on a graceful VM shutdown as described by the feature in a
Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1334982.
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
*"vdsmd.service"
*and *"libvirt-guests.service"* explained in bug
https://bugzilla.redhat.com/show_bug.cgi?id=720359.
<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.
Kind regards,
Petr Kotas
7 years, 5 months
ovirt-system-test failing on master
by Sandro Bonazzola
Hi,
just an heads up ovirt-system-test is failing[1] on master for:
[ ERROR ] Failed to execute stage 'Environment customization':
[u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-keystone-model >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-client >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-glance-model >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-glance-client >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-resteasy-connector >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-cinder-client >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-quantum-model >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-keystone-client >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
requires openstack-java-quantum-client >= 3.1.2',
u'ovirt-engine-4.2.0-0.0.master.20170630084548.gitbbd011e.el7.centos.noarch
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.
Thanks,
[1]
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1000/testRe...
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
7 years, 5 months
patch granularity, extracting patches
by Greg Sheremeta
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?
Best wishes,
Greg
--
Greg Sheremeta, MBA
Sr. Software Engineer
Red Hat, Inc.
gshereme(a)redhat.com
7 years, 5 months