January 2018 - Infra - Ovirt List Archives

[CQ]: 86903, 1 (ovirt-engine-api-model) 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 86903,1 (ovirt-engine-api-model) failed. However, this change seems not to be the root cause for this failure. Change 86692,1 (ovirt-engine-api-model) 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 86692,1 (ovirt-engine-api- model) 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/86903/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86692/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/372/

6 years, 9 months

1
0
0 / 0

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

by Roman Mohr (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jir... ] Roman Mohr commented on OVIRT-1867: ----------------------------------- In my opinion, having the secrets encrypted in the code is better, since you don't need accounts for engineers on CI to do that. A public rsa key can be made accessible for the whole world. With other words, the issue is exactly about the self-service and not about how to bind existing secrets. It is also related to OVIRT-1868. In combination with a Jenkinsfile, pretty much the whole yaml/script/chroot can be made obsolete, however that is a different story. > 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: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > 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#100077)

6 years, 9 months

1
0
0 / 0

[CQ]: 86869, 1 (otopi) 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 86869,1 (otopi) failed. However, this change seems not to be the root cause for this failure. Change 86679,4 (otopi) 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 86679,4 (otopi) 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/86869/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86679/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5160/

6 years, 9 months

1
0
0 / 0

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

by Daniel Belenky (oVirt JIRA)

This is a multi-part message in MIME format... ------------=_1517312708-12381-241 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jir... ] Daniel Belenky updated OVIRT-1867: ---------------------------------- Component/s: STDCI DSL Standard CI (Pipelines) > 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: By-EMAIL > Components: Standard CI (Pipelines), STDCI DSL > Reporter: Roman Mohr > Assignee: infra > > 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#100077) ------------=_1517312708-12381-241 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>Daniel Belenky updated OVIRT-1867:</h3> <pre> Component/s: STDCI DSL Standard CI (Pipelines)</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: By-EMAIL Components: Standard CI (Pipelines), STDCI DSL Reporter: Roman Mohr Assignee: infra</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#100077)</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> ------------=_1517312708-12381-241--

6 years, 9 months

1
0
0 / 0

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

by Daniel Belenky (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jir... ] Daniel Belenky commented on OVIRT-1867: --------------------------------------- We actually have a mechanism for secrets as environmental variables in stdci. Currently, we hold the secrets in a single secret file on our Jenkins master, and engineers can request those secrets as environmental variables via *.environment.yaml. The syntax is the same as for Kubernetes: {code:java} --- - name: MY_VAR valueFrom: secretKeyRef: name: MySecret1 value: password {code} The example above will bind the password field from MySecret1 to $MY_VAR inside the chroot created by STDCI. The one part which is still missing though is a common interface to allow projects to add the secrets to this file automatically. > 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: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > 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#100077)

6 years, 9 months

1
0
0 / 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles

by Roman Mohr (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jir... ] Roman Mohr updated OVIRT-1868: ------------------------------ Description: Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. With the Jenkinsfile the chroot based approach seems to be pretty obsolete, if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. was: Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. With the Jenkinsfile the chroot based approach seems to be pretty obsolate, if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. > Allow engineers to write Jenkinsfiles > ------------------------------------- > > Key: OVIRT-1868 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Roman Mohr > Assignee: infra > > Looks like standard-ci switched internally to use Jenkinsfiles. However it > would be very valuable for engineers, if they could just write their > Jenkinsfile, instead of all the usual standard-ci yamls/scripts. > With the Jenkinsfile the chroot based approach seems to be pretty obsolete, > if you allow people to use the docker agent for the Jenkinsfile. For > KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

6 years, 9 months

1
0
0 / 0

[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles

by Roman Mohr (oVirt JIRA)

Roman Mohr created OVIRT-1868: --------------------------------- Summary: Allow engineers to write Jenkinsfiles Key: OVIRT-1868 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. With the Jenkinsfile the chroot based approach seems to be pretty obsolate, if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

6 years, 9 months

1
0
0 / 0

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

by Roman Mohr (oVirt JIRA)

This is a multi-part message in MIME format... ------------=_1517308592-17438-377 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Roman Mohr created OVIRT-1867: --------------------------------- Summary: 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: By-EMAIL Reporter: Roman Mohr Assignee: infra 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#100077) ------------=_1517308592-17438-377 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>Roman Mohr created OVIRT-1867:</h3> <pre> Summary: 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: By-EMAIL Reporter: Roman Mohr Assignee: infra</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, …).</p> <p>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></p> <p>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.</p> <p>Benefit:</p> <pre>* Less manual intervention from CI team to add secrets to jobs * Strengthen the config-in-code thinking</pre> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</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> ------------=_1517308592-17438-377--

6 years, 9 months

1
0
0 / 0

[CQ]: 86910, 1 (ovirt-hosted-engine-setup) failed "ovirt-4.2" system tests

by oVirt Jenkins

Change 86910,1 (ovirt-hosted-engine-setup) is probably the reason behind recent system test failures in the "ovirt-4.2" 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/86910/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/370/

6 years, 9 months

1
0
0 / 0

[CQ]: e74f3bb (stage-gh-stdci2) failed "dummy-master" system tests, but isn't the failure root cause

by oVirt Jenkins

A system test invoked by the "dummy-master" change queue including change e74f3bb (stage-gh-stdci2) failed. However, this change seems not to be the root cause for this failure. Change 2ff79b3 (stage-gh-stdci2) 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 2ff79b3 (stage-gh-stdci2) 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://github.com/oVirt/stage-gh-stdci2/commit/e74f3bbc48cc8b76c599ec9c5... For further details about the change that seems to be the root cause behind the testing failures see: https://github.com/oVirt/stage-gh-stdci2/commit/2ff79b3f37717e65ab84a11c1... For failed test results see: http://jenkins-staging.phx.ovirt.org/job/dummy-master_change-queue-tester...

6 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra January 2018