[JIRA] (OVIRT-2177) Add Fedora master suite
by Gal Ben Haim (oVirt JIRA)
Gal Ben Haim created OVIRT-2177:
-----------------------------------
Summary: Add Fedora master suite
Key: OVIRT-2177
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2177
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: OST
Reporter: Gal Ben Haim
Assignee: infra
A master suite that runs on Fedora will help us to detect bugs on the next Centos.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100087)
7 years
Network test that randomly fails on CI
by Ala Hino
Hi,
From time to time, I see the following failure of a network test.
I understood from Ed that it is a CI known issue.
Would appreciate if this can be fixed ASAP. Thanks.
*09:59:56* self = <network.integration.ovs.ovs_info_test.TestOvsInfo
testMethod=test_ovs_info_with_sb_nic>*09:59:56* *09:59:56* def
test_ovs_info_with_sb_nic(self):*09:59:56* with dummy_device()
as nic:*09:59:56* > with _setup_ovs_network(self.ovsdb,
nic):*09:59:56* *09:59:56*
network/integration/ovs/ovs_info_test.py:78: *09:59:56* _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
*09:59:56* /usr/lib64/python2.7/contextlib.py:17: in
__enter__*09:59:56* return self.gen.next()*09:59:56*
network/integration/ovs/ovs_info_test.py:63: in
_setup_ovs_network*09:59:56* t.add(*_northbound_port())*09:59:56*
../lib/vdsm/network/ovs/driver/__init__.py:46: in __exit__*09:59:56*
self.result = self.commit()*09:59:56* _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ *09:59:56*
*09:59:56* self = <vdsm.network.ovs.driver.vsctl.Transaction object at
0x7fdbab22db50>*09:59:56* *09:59:56* def commit(self):*09:59:56*
if not self.commands:*09:59:56* return*09:59:56*
*09:59:56* timeout_option = []*09:59:56* if
self.timeout:*09:59:56* timeout_option = ['--timeout=' +
str(self.timeout)]*09:59:56* *09:59:56* args =
[]*09:59:56* for command in self.commands:*09:59:56*
args += ['--'] + command.cmd*09:59:56* exec_line =
[_ovs_vsctl_cmd()] + timeout_option + OUTPUT_FORMAT + args*09:59:56*
logging.debug('Executing commands: %s' % '
'.join(exec_line))*09:59:56* *09:59:56* rc, out, err =
netcmd.exec_sync(exec_line)*09:59:56* if rc != 0:*09:59:56*
err = err.splitlines()*09:59:56* if
OvsDBConnectionError.is_ovs_db_conn_error(err):*09:59:56*
raise OvsDBConnectionError('\n'.join(err))*09:59:56*
else:*09:59:56* raise ConfigNetworkError(*09:59:56*
ne.ERR_BAD_PARAMS,*09:59:56* >
'Executing commands failed: %s' % '\n'.join(err))*09:59:56* E
ConfigNetworkError: (21, 'Executing commands failed: ovs-vsctl:
cannot create a bridge named vdsmbr_test because a bridge named
vdsmbr_test already exists')*09:59:56* *09:59:56*
../lib/vdsm/network/ovs/driver/vsctl.py:78: ConfigNetworkError
7 years
[JIRA] (OVIRT-2176) oVirt CI should support fast moving platform
releases
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2176?page=com.atlassian.jir... ]
Barak Korren commented on OVIRT-2176:
-------------------------------------
Actually I think the user story is quite simple here - "As an ovirt developer, I would like to know as early as possible if platform changes are going to break oVirt so that I can react to them in a timely manner".
Or perhaps its "As a platform component developer I would like to know if changes I make are causing issues in oVirt as early as possible so I can eliminate those issues as early as possible and have newer version of my component be adopted by oVirt".
Actually which one of the two stories above we decide to aim for has significant influence on the kind of implementation we aim for.
> oVirt CI should support fast moving platform releases
> -----------------------------------------------------
>
> Key: OVIRT-2176
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2176
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Reporter: eyal edri
> Assignee: infra
>
> It's a bit hard to describe this as a user story, but the idea is to think what can we (oVirt CI) do keep oVirt stable as it is today, while taking into account the platforms that support it ( Ansible, Wildfly, CentOS, Fedora. OpenShift? ) will at some point shift to a faster release cadence which is much more frequent from today and possibly breaks oVirt users if the proper testing won't be done right.
> We are already doing good things today with oVirt System Tests and change queue, but it might not flexible and scalable enough if we'll start getting releases of layered products much faster.
> This solution might include tighter cooperation with the relevant CI teams for the other products, improved OST framework, and infrastructure changes to support it.
> Due to the side of this effort, it should be broken down into Epics and smaller user stories while grooming it.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100087)
7 years