[
https://ovirt-jira.atlassian.net/browse/OVIRT-2252?page=com.atlassian.jir...
]
Barak Korren updated OVIRT-2252:
--------------------------------
Description: "Since we only have one s390x slave, it is currently attached to
both the staging and the production CI systems, and while they use separate user accounts,
it turns out this is not enough to isolate them from one another.\r\n\r\nThe are several
issues that are caused by this configuration:\r\n# Tests that allocate a fixed network
port can fail if they are run by both systems at the same time - this happens in practice
when sending Python patchs to the '{{jenkins}}' repo because the
{{mirror_client.py}} tests start a web server on port 8675.\r\n# The {{mock_cleanup.sh}}
script that is being run by one system can time out trying to umount things from a mock
environment that was created and is being used by the other system.\r\n\r\n\r\n\r\n"
(was: One of the tests of the CI mirrors python package is starting up an HTTP server on a
fixed port number.
This can cause an issue if the same test is running in parallel on the same machine. This
typically cannot be an issue on the CI infra because it never runs more then one STDCI
thread at a time on a given slave.
This issue does arise specifically on the s390x slave because there the same slave is used
both by the staging and the production CI systems. In that case the two systems might be
trying to run the same test at the same time, so this can lead to port allocation
exceptions.
)
The s390x slave is used in parallel by both the staging and the
production CI systems
-------------------------------------------------------------------------------------
Key: OVIRT-2252
URL:
https://ovirt-jira.atlassian.net/browse/OVIRT-2252
Project: oVirt - virtualization made easy
Issue Type: Bug
Components: CI Mirrors
Reporter: Barak Korren
Assignee: infra
Since we only have one s390x slave, it is currently attached to both the staging and the
production CI systems, and while they use separate user accounts, it turns out this is not
enough to isolate them from one another.
The are several issues that are caused by this configuration:
# Tests that allocate a fixed network port can fail if they are run by both systems at
the same time - this happens in practice when sending Python patchs to the
'{{jenkins}}' repo because the {{mirror_client.py}} tests start a web server on
port 8675.
# The {{mock_cleanup.sh}} script that is being run by one system can time out trying to
umount things from a mock environment that was created and is being used by the other
system.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100087)