February 2018 - Infra - Ovirt List Archives

[oVirt CI] standard-enqueue - Build #9839 - FAILURE!

by jenkins＠jenkins.phx.ovirt.org

------=_Part_149_93651221.1518100761736 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/standard-enqueue/9839/ Build Name: #9839 Build Description: Gerrit: 87331 - ovirt-engine (3.6.13) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/87331 - title: build: post ovirt-engine-3.6.13.1 - project: ovirt-engine - branch: ovirt-engine-3.6-els - author: Sandro Bonazzola <sbonazzo(a)redhat.com> ------=_Part_149_93651221.1518100761736--

6 years, 10 months

1
1
0 / 0

[CQ]: 86860, 3 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "ovirt-master" change queue including change 86860,3 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 86920,2 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86920,2 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86860/3 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86920/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5400/

6 years, 10 months

1
0
0 / 0

[CQ]: 87271, 2 (ovirt-engine) failed "ovirt-4.2" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "ovirt-4.2" change queue including change 87271,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 87244,1 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 87244,1 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/87271/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/87244/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/624/

6 years, 10 months

1
0
0 / 0

[CQ]: 87246,1 (otopi) failed "ovirt-master" system tests

by oVirt Jenkins

Change 87246,1 (otopi) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/87246/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5395/

6 years, 10 months

3
2
0 / 0

[CQ]: 87270, 2 (ovirt-engine) failed "ovirt-4.2" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "ovirt-4.2" change queue including change 87270,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 87244,1 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 87244,1 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/87270/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/87244/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/621/

6 years, 10 months

1
0
0 / 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI

by Barak Korren (oVirt JIRA)

This is a multi-part message in MIME format... ------------=_1518096517-16706-206 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-1867: ------------------------------------- Here is an implementation scheme that can meet [~rmohr(a)redhat.com]'s UX requirements while still allowing STDCI projects to be portable between CI systems. First, we adopt or setup an online credentials storage service that has the following features: # It has a UI where users can login and upload or download credentials # It has functionality where it can generate key pairs while storing the private key and making the public key visible. # It supports a oAuth-like flow where a system can request access to certain credentials and the user can confirm or deny it. Second, we write a secrets provider that allows the user to refer to a set of credentials in the service above (As well as the service itself). When trying to provide the secrets, the system would request access via the credentials storage service. Third, we write an STDCI service that encapsulates the special-case flow where we get a private key from the secrets provider and use it tio decrypt files from the Git repo. > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > Labels: credentials > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100079) ------------=_1518096517-16706-206 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jir... ]</pre> <h3>Barak Korren commented on OVIRT-1867:</h3> <p>Here is an implementation scheme that can meet [~rmohr(a)redhat.com]'s UX requirements while still allowing STDCI projects to be portable between CI systems.</p> <p>First, we adopt or setup an online credentials storage service that has the following features: # It has a UI where users can login and upload or download credentials # It has functionality where it can generate key pairs while storing the private key and making the public key visible. # It supports a oAuth-like flow where a system can request access to certain credentials and the user can confirm or deny it.</p> <p>Second, we write a secrets provider that allows the user to refer to a set of credentials in the service above (As well as the service itself). When trying to provide the secrets, the system would request access via the credentials storage service.</p> <p>Third, we write an STDCI service that encapsulates the special-case flow where we get a private key from the secrets provider and use it tio decrypt files from the Git repo.</p> <blockquote><h3>Allow embedded secrets inside the source repo for CI</h3> <pre> Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: New Feature Components: Standard CI (Pipelines), STDCI DSL Reporter: Roman Mohr Assignee: infra Labels: credentials</pre> <p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a> Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100079)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BS..." 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> ------------=_1518096517-16706-206--

6 years, 10 months

1
0
0 / 0

[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI

by Barak Korren (oVirt JIRA)

This is a multi-part message in MIME format... ------------=_1518095376-22378-218 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jir... ] Barak Korren updated OVIRT-1867: -------------------------------- Labels: credentials (was: ) > Allow embedded secrets inside the source repo for CI > ---------------------------------------------------- > > Key: OVIRT-1867 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > Labels: credentials > > In order to improve the self-service capabilities of standard-ci it is > important for projects, that they can add their own secrets to projects (to > reach external services, e.g. docker hub, ...). > Travis has a very nice system which helps engineers there: > https://docs.travis-ci.com/user/encryption-keys/ > Basically the CI system needs to generate a public/private key pair for > every enabled git repo. The engineer simply fetches the public key via a > well know URL and encrypts the secrets. Then the encrypted secret can be > made part of the source repo. Before the tests are run the CI system > decrypts the secrets. Than can play together pretty well with Jenkinsfiles > too. > Benefit: > * Less manual intervention from CI team to add secrets to jobs > * Strengthen the config-in-code thinking -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100079) ------------=_1518095376-22378-218 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jir... ]</pre> <h3>Barak Korren updated OVIRT-1867:</h3> <pre>Labels: credentials (was: )</pre> <blockquote><h3>Allow embedded secrets inside the source repo for CI</h3> <pre> Key: OVIRT-1867 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867 Project: oVirt - virtualization made easy Issue Type: New Feature Components: Standard CI (Pipelines), STDCI DSL Reporter: Roman Mohr Assignee: infra Labels: credentials</pre> <p>In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: <a href="https://docs.travis-ci.com/user/encryption-keys/">https://docs.travis-ci.com/user/encryption-keys/</a> Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100079)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BS..." 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> ------------=_1518095376-22378-218--

6 years, 10 months

1
0
0 / 0

[CQ]: 87269, 2 (ovirt-engine) failed "ovirt-4.2" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "ovirt-4.2" change queue including change 87269,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 87244,1 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 87244,1 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/87269/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/87244/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/618/

6 years, 10 months

1
0
0 / 0

[CQ]: 87268, 2 (ovirt-engine) failed "ovirt-4.2" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "ovirt-4.2" change queue including change 87268,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 87244,1 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 87244,1 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/87268/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/87244/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/615/

6 years, 10 months

1
0
0 / 0

[CQ]: 87050, 8 (ovirt-hosted-engine-setup) failed "ovirt-master" system tests

by oVirt Jenkins

Change 87050,8 (ovirt-hosted-engine-setup) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/87050/8 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5390/

6 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra February 2018