[JIRA] (OVIRT-1068) Make suit-type be the same sting everywhere
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1068?page=com.atlassian.jir... ]
Barak Korren reassigned OVIRT-1068:
-----------------------------------
Assignee: Barak Korren (was: infra)
> Make suit-type be the same sting everywhere
> -------------------------------------------
>
> Key: OVIRT-1068
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1068
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: Barak Korren
> Priority: High
>
> The 'suit-type' is parth of the OST suit name that determines which type of suit is it. For example: 'basic', 'upgrade', etc.
> In various point it is important to know the suit-type to figure out where the testing suit will look for particular files. This is why the suit-type is often held in a separate variable.
> To allow working with OST suits, it is desirable that the value of the 'suit-type' will be a consistent string everywhere. This is the case with the 'basic' suits, but this is not the case with suites like the (currently named) 'he_basic' suit.
> For 'he_basic' (and other suites that have multi-worded names) the suit type is specified as 'he_basic' in YAML and in the names of the automation scripts, but as 'he-basic' in the name of the suit directory in the OST source repo.
> In the CI system we typically regard underscore ('_') as a separator and hyphen ('\-') as a joiner. So it is desirable to rename all the OST automation scripts and fix the YAML so that all OST suits will only have hyphens ('\-') in their names.
--
This message was sent by Atlassian JIRA
(v1000.695.3#100025)
7 years, 10 months
[JIRA] (OVIRT-1068) Make suit-type be the same sting everywhere
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1068?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1068:
--------------------------------
Description:
The 'suit-type' is parth of the OST suit name that determines which type of suit is it. For example: 'basic', 'upgrade', etc.
In various point it is important to know the suit-type to figure out where the testing suit will look for particular files. This is why the suit-type is often held in a separate variable.
To allow working with OST suits, it is desirable that the value of the 'suit-type' will be a consistent string everywhere. This is the case with the 'basic' suits, but this is not the case with suites like the (currently named) 'he_basic' suit.
For 'he_basic' (and other suites that have multi-worded names) the suit type is specified as 'he_basic' in YAML and in the names of the automation scripts, but as 'he-basic' in the name of the suit directory in the OST source repo.
In the CI system we typically regard underscore ('_') as a separator and hyphen ('\-') as a joiner. So it is desirable to rename all the OST automation scripts and fix the YAML so that all OST suits will only have hyphens ('\-') in their names.
was:
The 'suit-type' is parth of the OST suit name that determines which type of suit is it. For example: 'basic', 'upgrade', etc.
In various point it is important to know the suit-type to figure out where the testing suit will look for particular files. This is why the suit-type is often held in a separate variable.
To allow working with OST suits, it is desirable that the value of the 'suit-type' will be a consistent string everywhere. This is the case with the 'basic' suits, but this is not the case with suites like the (currently named) 'he_basic' suit.
For 'he_basic' (and other suites that have multi-worded names) the suit type is specified as 'he_basic' in YAML and in the names of the automation scripts, but as 'he-basic' in the name of the suit directory in the OST source repo.
In the CI system we typically regard underscore ('_') as a separator and hyphen ('-') as a joiner. So it is desirable to rename all the OST automation scripts and fix the YAML so that all OST suits will only have hyphens ('-') in their names.
> Make suit-type be the same sting everywhere
> -------------------------------------------
>
> Key: OVIRT-1068
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1068
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
>
> The 'suit-type' is parth of the OST suit name that determines which type of suit is it. For example: 'basic', 'upgrade', etc.
> In various point it is important to know the suit-type to figure out where the testing suit will look for particular files. This is why the suit-type is often held in a separate variable.
> To allow working with OST suits, it is desirable that the value of the 'suit-type' will be a consistent string everywhere. This is the case with the 'basic' suits, but this is not the case with suites like the (currently named) 'he_basic' suit.
> For 'he_basic' (and other suites that have multi-worded names) the suit type is specified as 'he_basic' in YAML and in the names of the automation scripts, but as 'he-basic' in the name of the suit directory in the OST source repo.
> In the CI system we typically regard underscore ('_') as a separator and hyphen ('\-') as a joiner. So it is desirable to rename all the OST automation scripts and fix the YAML so that all OST suits will only have hyphens ('\-') in their names.
--
This message was sent by Atlassian JIRA
(v1000.695.3#100025)
7 years, 10 months
[JIRA] (OVIRT-1068) Make suit-type be the same sting everywhere
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1068?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1068:
--------------------------------
Epic Link: OVIRT-400
> Make suit-type be the same sting everywhere
> -------------------------------------------
>
> Key: OVIRT-1068
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1068
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Components: Jenkins
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
>
> The 'suit-type' is parth of the OST suit name that determines which type of suit is it. For example: 'basic', 'upgrade', etc.
> In various point it is important to know the suit-type to figure out where the testing suit will look for particular files. This is why the suit-type is often held in a separate variable.
> To allow working with OST suits, it is desirable that the value of the 'suit-type' will be a consistent string everywhere. This is the case with the 'basic' suits, but this is not the case with suites like the (currently named) 'he_basic' suit.
> For 'he_basic' (and other suites that have multi-worded names) the suit type is specified as 'he_basic' in YAML and in the names of the automation scripts, but as 'he-basic' in the name of the suit directory in the OST source repo.
> In the CI system we typically regard underscore ('_') as a separator and hyphen ('-') as a joiner. So it is desirable to rename all the OST automation scripts and fix the YAML so that all OST suits will only have hyphens ('-') in their names.
--
This message was sent by Atlassian JIRA
(v1000.695.3#100025)
7 years, 10 months
[JIRA] (OVIRT-1068) Make suit-type be the same sting everywhere
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-1068:
-----------------------------------
Summary: Make suit-type be the same sting everywhere
Key: OVIRT-1068
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1068
Project: oVirt - virtualization made easy
Issue Type: Bug
Components: Jenkins
Reporter: Barak Korren
Assignee: infra
Priority: High
The 'suit-type' is parth of the OST suit name that determines which type of suit is it. For example: 'basic', 'upgrade', etc.
In various point it is important to know the suit-type to figure out where the testing suit will look for particular files. This is why the suit-type is often held in a separate variable.
To allow working with OST suits, it is desirable that the value of the 'suit-type' will be a consistent string everywhere. This is the case with the 'basic' suits, but this is not the case with suites like the (currently named) 'he_basic' suit.
For 'he_basic' (and other suites that have multi-worded names) the suit type is specified as 'he_basic' in YAML and in the names of the automation scripts, but as 'he-basic' in the name of the suit directory in the OST source repo.
In the CI system we typically regard underscore ('_') as a separator and hyphen ('-') as a joiner. So it is desirable to rename all the OST automation scripts and fix the YAML so that all OST suits will only have hyphens ('-') in their names.
--
This message was sent by Atlassian JIRA
(v1000.695.3#100025)
7 years, 10 months
[JIRA] (OVIRT-1067) Java updates without restarting Jenkins agent are probably causing jobs to fail
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1067?page=com.atlassian.jir... ]
Barak Korren reassigned OVIRT-1067:
-----------------------------------
Assignee: Evgheni Dereveanchin (was: infra)
> Java updates without restarting Jenkins agent are probably causing jobs to fail
> -------------------------------------------------------------------------------
>
> Key: OVIRT-1067
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1067
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Reporter: Barak Korren
> Assignee: Evgheni Dereveanchin
>
> A [recently invoked|http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_3.6/452...] system teasts job failed with the following error:
> {code}
> java.io.IOException: remote file operation failed: /home/jenkins/workspace/test-repo_ovirt_experimental_3.6 at hudson.remoting.Channel@432401f8:el7-vm26.phx.ovirt.org: java.io.IOException: Remote call on el7-vm26.phx.ovirt.org failed
> at hudson.FilePath.act(FilePath.java:992)
> ...
> Caused by: java.lang.InternalError: java.io.FileNotFoundException: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/jre/lib/resources.jar
> at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1003)
> at sun.misc.URLClassPath.getResource(URLClassPath.java:212)
> ...
> {code}
> Looking at {{el7-vm26.phx.ovirt.org failed}} where this happened proved that indeed the file '{{/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/jre/lib/resources.jar}}' does not exist on the node. The file '{{/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre/lib/resources.jar}}' does exist however.
> Further examination in the logs revealed that the system's java version was recently updated:
> {code}
> Jan 21 20:19:36 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-headless-1.8.0.121-0.b13.el7_3.x86_64
> Jan 21 20:19:38 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64
> Jan 21 20:19:40 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-devel-1.8.0.121-0.b13.el7_3.x86_64
> {code}
> I suppose the issue is does to the system Jave and libraries being updated while the Jenkins agent was still running and trying to use the older libraries.
> I suggest we endure that the Jenkins agent is shut down every time package updates are done on the node and restarted afterwards. This could be done by setting the node to "offline" in Jenkins.
--
This message was sent by Atlassian JIRA
(v1000.695.3#100025)
7 years, 10 months
[JIRA] (OVIRT-1067) Java updates without restarting Jenkins agent are probably causing jobs to fail
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-1067:
-----------------------------------
Summary: Java updates without restarting Jenkins agent are probably causing jobs to fail
Key: OVIRT-1067
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1067
Project: oVirt - virtualization made easy
Issue Type: Bug
Reporter: Barak Korren
Assignee: infra
A [recently invoked|http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_3.6/452...] system teasts job failed with the following error:
{code}
java.io.IOException: remote file operation failed: /home/jenkins/workspace/test-repo_ovirt_experimental_3.6 at hudson.remoting.Channel@432401f8:el7-vm26.phx.ovirt.org: java.io.IOException: Remote call on el7-vm26.phx.ovirt.org failed
at hudson.FilePath.act(FilePath.java:992)
...
Caused by: java.lang.InternalError: java.io.FileNotFoundException: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/jre/lib/resources.jar
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1003)
at sun.misc.URLClassPath.getResource(URLClassPath.java:212)
...
{code}
Looking at {{el7-vm26.phx.ovirt.org failed}} where this happened proved that indeed the file '{{/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/jre/lib/resources.jar}}' does not exist on the node. The file '{{/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre/lib/resources.jar}}' does exist however.
Further examination in the logs revealed that the system's java version was recently updated:
{code}
Jan 21 20:19:36 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-headless-1.8.0.121-0.b13.el7_3.x86_64
Jan 21 20:19:38 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64
Jan 21 20:19:40 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-devel-1.8.0.121-0.b13.el7_3.x86_64
{code}
I suppose the issue is does to the system Jave and libraries being updated while the Jenkins agent was still running and trying to use the older libraries.
I suggest we endure that the Jenkins agent is shut down every time package updates are done on the node and restarted afterwards. This could be done by setting the node to "offline" in Jenkins.
--
This message was sent by Atlassian JIRA
(v1000.695.3#100025)
7 years, 10 months
[JIRA] (OVIRT-1067) Java updates without restarting Jenkins agent are probably causing jobs to fail
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1067?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1067:
--------------------------------
Epic Link: OVIRT-403
> Java updates without restarting Jenkins agent are probably causing jobs to fail
> -------------------------------------------------------------------------------
>
> Key: OVIRT-1067
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1067
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Reporter: Barak Korren
> Assignee: infra
>
> A [recently invoked|http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_3.6/452...] system teasts job failed with the following error:
> {code}
> java.io.IOException: remote file operation failed: /home/jenkins/workspace/test-repo_ovirt_experimental_3.6 at hudson.remoting.Channel@432401f8:el7-vm26.phx.ovirt.org: java.io.IOException: Remote call on el7-vm26.phx.ovirt.org failed
> at hudson.FilePath.act(FilePath.java:992)
> ...
> Caused by: java.lang.InternalError: java.io.FileNotFoundException: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/jre/lib/resources.jar
> at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1003)
> at sun.misc.URLClassPath.getResource(URLClassPath.java:212)
> ...
> {code}
> Looking at {{el7-vm26.phx.ovirt.org failed}} where this happened proved that indeed the file '{{/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/jre/lib/resources.jar}}' does not exist on the node. The file '{{/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre/lib/resources.jar}}' does exist however.
> Further examination in the logs revealed that the system's java version was recently updated:
> {code}
> Jan 21 20:19:36 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-headless-1.8.0.121-0.b13.el7_3.x86_64
> Jan 21 20:19:38 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64
> Jan 21 20:19:40 el7-vm26 yum[31962]: Updated: 1:java-1.8.0-openjdk-devel-1.8.0.121-0.b13.el7_3.x86_64
> {code}
> I suppose the issue is does to the system Jave and libraries being updated while the Jenkins agent was still running and trying to use the older libraries.
> I suggest we endure that the Jenkins agent is shut down every time package updates are done on the node and restarted afterwards. This could be done by setting the node to "offline" in Jenkins.
--
This message was sent by Atlassian JIRA
(v1000.695.3#100025)
7 years, 10 months