[ OST Failure Report ] [ oVirt Master ] [ 06-11-2017 ] [ 002_bootstrap.verify_add_hosts ]
by Dafna Ron
This is a multi-part message in MIME format.
--------------88DD9FCD3B3DDEA34D4EAEF4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi,
We failed test 002_bootstrap.verify_add_hosts
I can see we only tried to install one of the hosts (host-0) and failed.
the second host has no log which means we did not try to deploy it.
The error suggests that we ovirt-imageio-daemon failed to start.
However, there is another message that I think should be addressed about
conflicting vdsm and libvirt configurations.
**
*Link to suspected patches: https://gerrit.ovirt.org/#/c/83612/*
*
Link to Job:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/
Link to all logs:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifact/
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifa...
*
*
*(Relevant) error snippet from the log: *
*
<error>
\*
2017-11-06 02:56:46,526-0500 DEBUG otopi.plugins.ovirt_host_deploy.vdsm.packages plugin.execute:921 execute-output: ('/usr/bin/vdsm-tool', 'configure', '--force') stdout:
Checking configuration status...
abrt is not configured for vdsm
WARNING: LVM local configuration: /etc/lvm/lvmlocal.conf is not based on vdsm configuration
lvm requires configuration
libvirt is not configured for vdsm yet
FAILED: conflicting vdsm and libvirt-qemu tls configuration.
vdsm.conf with ssl=True requires the following changes:
libvirtd.conf: listen_tcp=0, auth_tcp="sasl", listen_tls=1
qemu.conf: spice_tls=1.
multipath requires configuration
2017-11-06 02:56:47,551-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/usr/bin/systemctl', 'start', 'ovirt-imageio-daemon.service') stderr:
Job for ovirt-imageio-daemon.service failed because the control process exited with error code. See "systemctl status ovirt-imageio-daemon.service" and "journalctl -xe" for details.
2017-11-06 02:56:47,552-0500 DEBUG otopi.context context._executeMethod:143 method exception
Traceback (most recent call last):
File "/tmp/ovirt-R4R8gZhaQI/pythonlib/otopi/context.py", line 133, in _executeMethod
method['method']()
File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/ovirt-host-deploy/vdsm/packages.py", line 179, in _start
self.services.state('ovirt-imageio-daemon', True)
File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/otopi/services/systemd.py", line 141, in state
service=name,
RuntimeError: Failed to start service 'ovirt-imageio-daemon'
2017-11-06 02:56:47,553-0500 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Closing up': Failed to start service 'ovirt-imageio-daemon'
**
*</error>*
*
*
--------------88DD9FCD3B3DDEA34D4EAEF4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi, <br>
</p>
<p>We failed test 002_bootstrap.verify_add_hosts</p>
<p>I can see we only tried to install one of the hosts (host-0) and
failed. the second host has no log which means we did not try to
deploy it. <br>
</p>
<p>The error suggests that we ovirt-imageio-daemon failed to start.
However, there is another message that I think should be addressed
about conflicting vdsm and libvirt configurations. <br>
</p>
<p><b style="font-weight:normal;"
id="docs-internal-guid-5859b7a1-911e-5616-3cbc-97286587db85">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to suspected patches: <a class="moz-txt-link-freetext" href="https://gerrit.ovirt.org/#/c/83612/">https://gerrit.ovirt.org/#/c/83612/</a></span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to Job: <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/</a></span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to all logs: <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifact/">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifact/</a></span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">
</span></p>
<a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifa...">http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3626/artifa...</a></b></p>
<p><b style="font-weight:normal;"
id="docs-internal-guid-5859b7a1-911e-5616-3cbc-97286587db85"><br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">(Relevant) error snippet from the log: </span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"><error></span></p>
\</b><br>
</p>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">2017-11-06 02:56:46,526-0500 DEBUG otopi.plugins.ovirt_host_deploy.vdsm.packages plugin.execute:921 execute-output: ('/usr/bin/vdsm-tool', 'configure', '--force') stdout:
Checking configuration status...
abrt is not configured for vdsm
WARNING: LVM local configuration: /etc/lvm/lvmlocal.conf is not based on vdsm configuration
lvm requires configuration
libvirt is not configured for vdsm yet
FAILED: conflicting vdsm and libvirt-qemu tls configuration.
vdsm.conf with ssl=True requires the following changes:
libvirtd.conf: listen_tcp=0, auth_tcp="sasl", listen_tls=1
qemu.conf: spice_tls=1.
multipath requires configuration
</pre>
<br class="Apple-interchange-newline">
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">2017-11-06 02:56:47,551-0500 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/usr/bin/systemctl', 'start', 'ovirt-imageio-daemon.service') stderr:
Job for ovirt-imageio-daemon.service failed because the control process exited with error code. See "systemctl status ovirt-imageio-daemon.service" and "journalctl -xe" for details.
2017-11-06 02:56:47,552-0500 DEBUG otopi.context context._executeMethod:143 method exception
Traceback (most recent call last):
File "/tmp/ovirt-R4R8gZhaQI/pythonlib/otopi/context.py", line 133, in _executeMethod
method['method']()
File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/ovirt-host-deploy/vdsm/packages.py", line 179, in _start
self.services.state('ovirt-imageio-daemon', True)
File "/tmp/ovirt-R4R8gZhaQI/otopi-plugins/otopi/services/systemd.py", line 141, in state
service=name,
RuntimeError: Failed to start service 'ovirt-imageio-daemon'
2017-11-06 02:56:47,553-0500 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Closing up': Failed to start service 'ovirt-imageio-daemon'</pre>
<p><b style="font-weight:normal;"
id="docs-internal-guid-5859b7a1-911e-5616-3cbc-97286587db85">
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"></error></span></p>
<br>
</b></p>
</body>
</html>
--------------88DD9FCD3B3DDEA34D4EAEF4--
6 years, 10 months
[JIRA] (OVIRT-1743) ci please build and send to OST
by danken (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1743?page=com.atlassian.jir... ]
danken commented on OVIRT-1743:
-------------------------------
If OST was cheap and quick, it would be lovely to run on any patch. It can also be run after a +2 from a maintainer, or after a workflow+1, providing a verified +0.5 to a patch. I don't know if that's what you're aiming at.
> ci please build and send to OST
> -------------------------------
>
> Key: OVIRT-1743
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1743
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: oVirt CI
> Reporter: danken
> Assignee: infra
> Labels: change-queue
>
> Can you please automate the frequent process, which is slow and error prone?
> I am writing a patch, and would like to test it in ost. now I need to
> * "ci please build"
> * copy el7 url
> * wait for el7 build to finish
> * copy artifacts url to ovirt--system-test-manual, start it
> * copy the ost run URL to the gerrit patch, so I have it for reference of failure/success.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)
6 years, 10 months
[JIRA] (OVIRT-1746) Make stand-alone upstream source collection and updating tool
by Barak Korren (oVirt JIRA)
This is a multi-part message in MIME format...
------------=_1510046714-26505-534
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1746?page=com.atlassian.jir... ]
Barak Korren reassigned OVIRT-1746:
-----------------------------------
Assignee: Barak Korren (was: infra)
> Make stand-alone upstream source collection and updating tool
> -------------------------------------------------------------
>
> Key: OVIRT-1746
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: oVirt CI
> Reporter: Barak Korren
> Assignee: Barak Korren
> Labels: poll-upstream-sources, upstream-source-collector
>
> The upstream source collection code is currently built included in two different files - "{{upstream-source-collector.py}}" and "{{poll-upstream-sources.py}}". The files reside in "{{jobs/confs/python-scripts}}" which in turn mean they are mean for embedding into jobs by JJB.
> This situation causes several issues:
> # It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally
> # There is code duplication between the two python scripts
> # Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example)
> # It is impossible to use the code from pipelines (See OVIRT-1745)
> # It is not east to add tests for the code
> It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the '{{scripts}}' directory.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)
------------=_1510046714-26505-534
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
<html><body>
<pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1746?page=com.atlassian.jir... ]</pre>
<h3>Barak Korren reassigned OVIRT-1746:</h3>
<pre>Assignee: Barak Korren (was: infra)</pre>
<blockquote><h3>Make stand-alone upstream source collection and updating tool</h3>
<pre> Key: OVIRT-1746
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: oVirt CI
Reporter: Barak Korren
Assignee: Barak Korren
Labels: poll-upstream-sources, upstream-source-collector</pre>
<p>The upstream source collection code is currently built included in two different files – “{{upstream-source-collector.py}}” and “{{poll-upstream-sources.py}}”. The files reside in “{{jobs/confs/python-scripts}}” which in turn mean they are mean for embedding into jobs by JJB. This situation causes several issues: # It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally # There is code duplication between the two python scripts # Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example) # It is impossible to use the code from pipelines (See OVIRT-1745) # It is not east to add tests for the code It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the ‘{{scripts}}’ directory.</p></blockquote>
<p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070)</p>
<img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BCmpYL..." alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>
------------=_1510046714-26505-534--
6 years, 10 months
[JIRA] (OVIRT-1746) Make stand-alone upstream source collection and updating tool
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-1746:
-----------------------------------
Summary: Make stand-alone upstream source collection and updating tool
Key: OVIRT-1746
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: oVirt CI
Reporter: Barak Korren
Assignee: infra
The upstream source collection code is currently built included in two different files - "{{upstream-source-collector.py}}" and "{{poll-upstream-sources.py}}". The files reside in "{{jobs/confs/python-scripts}}" which in turn mean they are mean for embedding into jobs by JJB.
This situation causes several issues:
# It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally
# There is code duplication between the two python scripts
# Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example)
# It is impossible to use the code from pipelines (See OVIRT-1745)
# It is not east to add tests for the code
It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the '{{scripts}}' directory.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)
6 years, 10 months
[JIRA] (OVIRT-1746) Make stand-alone upstream source collection and updating tool
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1746?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1746:
--------------------------------
Epic Link: OVIRT-400
> Make stand-alone upstream source collection and updating tool
> -------------------------------------------------------------
>
> Key: OVIRT-1746
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1746
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: oVirt CI
> Reporter: Barak Korren
> Assignee: infra
> Labels: poll-upstream-sources, upstream-source-collector
>
> The upstream source collection code is currently built included in two different files - "{{upstream-source-collector.py}}" and "{{poll-upstream-sources.py}}". The files reside in "{{jobs/confs/python-scripts}}" which in turn mean they are mean for embedding into jobs by JJB.
> This situation causes several issues:
> # It is not easy for users to use these scripts locally, and hence its difficult to build or test repos that include upstream source dependencies locally
> # There is code duplication between the two python scripts
> # Adding certain features is harder because it requires one of the scripts to have access to code that resides in the other script (See OVIRT-1641 for example)
> # It is impossible to use the code from pipelines (See OVIRT-1745)
> # It is not east to add tests for the code
> It is desirable to have the upstream source handling code be concentrated into a single tool that resides in the '{{scripts}}' directory.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)
6 years, 10 months
[JIRA] (OVIRT-1680) Adapt STDCI pipelines for use in Gerrit projects
by Barak Korren (oVirt JIRA)
This is a multi-part message in MIME format...
------------=_1510045336-25494-507
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1680?page=com.atlassian.jir... ]
Barak Korren commented on OVIRT-1680:
-------------------------------------
Adding OVIRT-1745 as a blocker because we need the upstream source collection code to support pipelines before we can migrate everything to pipelines.
> Adapt STDCI pipelines for use in Gerrit projects
> ------------------------------------------------
>
> Key: OVIRT-1680
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1680
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Components: oVirt CI
> Reporter: Barak Korren
> Assignee: infra
> Labels: gerrit, standard-ci
>
> So far work on OVIRT-1522 focused on GitHub, and it is now feature-complete.
> Now its time to make this work also available for Gerrit projects.
> OVIRT-1629 is a blocker for this ticket because the '{{automation.yaml}}' implementation in the current STDCI pipelines does not yet support everything that the existing JJB YAML does.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)
------------=_1510045336-25494-507
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
<html><body>
<pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1680?page=com.atlassian.jir... ]</pre>
<h3>Barak Korren commented on OVIRT-1680:</h3>
<p>Adding OVIRT-1745 as a blocker because we need the upstream source collection code to support pipelines before we can migrate everything to pipelines.</p>
<blockquote><h3>Adapt STDCI pipelines for use in Gerrit projects</h3>
<pre> Key: OVIRT-1680
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1680
Project: oVirt - virtualization made easy
Issue Type: Improvement
Components: oVirt CI
Reporter: Barak Korren
Assignee: infra
Labels: gerrit, standard-ci</pre>
<p>So far work on OVIRT-1522 focused on GitHub, and it is now feature-complete. Now its time to make this work also available for Gerrit projects. OVIRT-1629 is a blocker for this ticket because the ‘{{automation.yaml}}’ implementation in the current STDCI pipelines does not yet support everything that the existing JJB YAML does.</p></blockquote>
<p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070)</p>
<img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BCmpYL..." alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>
------------=_1510045336-25494-507--
6 years, 10 months
[JIRA] (OVIRT-1745) Make upstream source collection and polling code usable for pipelines
by Barak Korren (oVirt JIRA)
This is a multi-part message in MIME format...
------------=_1510045269-22278-509
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1745?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-1745:
--------------------------------
Epic Link: OVIRT-400
> Make upstream source collection and polling code usable for pipelines
> ---------------------------------------------------------------------
>
> Key: OVIRT-1745
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1745
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: oVirt CI
> Reporter: Barak Korren
> Assignee: infra
> Labels: poll-upstream-sources, upstream-source-collector
>
> The upstream source collection and polling code is currently only suitable for use in Free-Style jobs. This is because:
> # We support having 'jenkins' repositories (Where jobs expect STDCI code to be found) use the upstream sources mechanism to get the actual code from the main 'jenkins' repo in gerrit.ovirt.org
> # This creates a situation where in order to get the STDCI code we need to run the upstream sources code
> # This creates a chicken and and egg problem because the upstream sources code is part of the STDCI code
> # To solve this issue we simply embedded the upstream sources code into the job code by using '{{#include}}' in JJB rather then running it as a stand-alone script.
> # This technique is not usable for pipelines, so we need to come with a different solution and make the required adjustments to the source collection and polling code.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)
------------=_1510045269-22278-509
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
<html><body>
<pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1745?page=com.atlassian.jir... ]</pre>
<h3>Barak Korren updated OVIRT-1745:</h3>
<pre>Epic Link: OVIRT-400</pre>
<blockquote><h3>Make upstream source collection and polling code usable for pipelines</h3>
<pre> Key: OVIRT-1745
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1745
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: oVirt CI
Reporter: Barak Korren
Assignee: infra
Labels: poll-upstream-sources, upstream-source-collector</pre>
<p>The upstream source collection and polling code is currently only suitable for use in Free-Style jobs. This is because: # We support having ‘jenkins’ repositories (Where jobs expect STDCI code to be found) use the upstream sources mechanism to get the actual code from the main ‘jenkins’ repo in gerrit.ovirt.org # This creates a situation where in order to get the STDCI code we need to run the upstream sources code # This creates a chicken and and egg problem because the upstream sources code is part of the STDCI code # To solve this issue we simply embedded the upstream sources code into the job code by using ‘{{#include}}’ in JJB rather then running it as a stand-alone script. # This technique is not usable for pipelines, so we need to come with a different solution and make the required adjustments to the source collection and polling code.</p></blockquote>
<p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100070)</p>
<img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BCmpYL..." alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>
------------=_1510045269-22278-509--
6 years, 10 months
[JIRA] (OVIRT-1745) Make upstream source collection and polling code usable for pipelines
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-1745:
-----------------------------------
Summary: Make upstream source collection and polling code usable for pipelines
Key: OVIRT-1745
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1745
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: oVirt CI
Reporter: Barak Korren
Assignee: infra
The upstream source collection and polling code is currently only suitable for use in Free-Style jobs. This is because:
# We support having 'jenkins' repositories (Where jobs expect STDCI code to be found) use the upstream sources mechanism to get the actual code from the main 'jenkins' repo in gerrit.ovirt.org
# This creates a situation where in order to get the STDCI code we need to run the upstream sources code
# This creates a chicken and and egg problem because the upstream sources code is part of the STDCI code
# To solve this issue we simply embedded the upstream sources code into the job code by using '{{#include}}' in JJB rather then running it as a stand-alone script.
# This technique is not usable for pipelines, so we need to come with a different solution and make the required adjustments to the source collection and polling code.
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100070)
6 years, 10 months
