[JIRA] (OVIRT-2617) Allow rerunning only failed test lanes
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38998#comment-38998 ] Roman Mohr commented on OVIRT-2617: --- So think about sprint ends. Many people have PRs, they produce load. Things are already a little bit more unstable than usual, which will increase the amount of failed lanes. So people will hit "retest this please" more often ... > Allow rerunning only failed test lanes > -- > > Key: OVIRT-2617 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2617 > Project: oVirt - virtualization made easy > Issue Type: New Feature >Reporter: Roman Mohr >Assignee: infra > > Hi, > In KubeVirt we run a lot of differnent test lanes. Even if our tests are > written in a good way and if the underlying CI infra is stable and fast, > there will always be cases where for-whatever reason one or two tests can > fail out of hundreds in a lane. > It would be very helpful if we could have a /retest command or something > similar where only failed lanes are re-run. That would be similar to how it > is handled in Kubernetes. > Right now it is an all-or-nothing thing. > What I would expect, is that it is still possible to see the test history > somewhere then (e.g. the first two attempts where it failed and then the > third one where it succeeds). > Best Regards, > Roman -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/FNVRP35ABGSEXJHAT5LLYOEZEOQIE4XH/
[JIRA] (OVIRT-2617) Allow rerunning only failed test lanes
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38997#comment-38997 ] Roman Mohr commented on OVIRT-2617: --- Well if one suspicious lane fails, we write "retest this please". This runs everything again. > Allow rerunning only failed test lanes > -- > > Key: OVIRT-2617 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2617 > Project: oVirt - virtualization made easy > Issue Type: New Feature >Reporter: Roman Mohr >Assignee: infra > > Hi, > In KubeVirt we run a lot of differnent test lanes. Even if our tests are > written in a good way and if the underlying CI infra is stable and fast, > there will always be cases where for-whatever reason one or two tests can > fail out of hundreds in a lane. > It would be very helpful if we could have a /retest command or something > similar where only failed lanes are re-run. That would be similar to how it > is handled in Kubernetes. > Right now it is an all-or-nothing thing. > What I would expect, is that it is still possible to see the test history > somewhere then (e.g. the first two attempts where it failed and then the > third one where it succeeds). > Best Regards, > Roman -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/72YVV5SJ6XGTZCZSZAGQM34IIKWAATLP/
[JIRA] (OVIRT-2590) Cache Docker images in the datacenter
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38996#comment-38996 ] Roman Mohr commented on OVIRT-2590: --- Thinking about our CI images it can avoid peaks on the network consumption. Right now you need all of our lanes to have run on each bare-metal machine until all nodes have a cache for each image. They have up to 8gb. It is another measure to reduce the amount of failing tests because of networking issues. Setting it up should be pretty simple. The mirror needs then just to be injected before starting docker. > Cache Docker images in the datacenter > - > > Key: OVIRT-2590 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2590 > Project: oVirt - virtualization made easy > Issue Type: Improvement >Reporter: Roman Mohr >Assignee: infra > > What? > As a user, I expect that I don't have to care about caching to speed up > builds for the good of the CI system itself. > Right now there exists a whitelist for docker images, which will not be > remove from the build slot after the build. Instead of that I expect a > clean build environment and that in general all images which I regularly > use are cached in the cluster via e.g. a pull-through-cache [1]. > Why? > 1) Caching in a build slot is not very effective. CI runs do really-a-lot > of almost identical things in a small time-window (e.g. days). If caching > happens in the build-slot and many slots are present, then the cache > utilization will be very low. > 2) Whitelisting docker images extra for a slot where the registry runs in, > is very error prone and since it is not cached across the cluster it is > also very intransparent what the clear benefit for the user is. Especially > when thinking about scaling a CI system, that seems to leak internal > optimizations to the user. Fast builds are twice as important for the CI > system than they are for the users (by default faster and lower utilization > is always better than asking people to optimize on their side). > [1] https://docs.docker.com/registry/recipes/mirror/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100098) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/G5VZHUUYMIXDH7BR3AXMSYIYFHNWPGFU/
[JIRA] (OVIRT-2617) Allow rerunning only failed test lanes
Roman Mohr created OVIRT-2617: - Summary: Allow rerunning only failed test lanes Key: OVIRT-2617 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2617 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra Hi, In KubeVirt we run a lot of differnent test lanes. Even if our tests are written in a good way and if the underlying CI infra is stable and fast, there will always be cases where for-whatever reason one or two tests can fail out of hundreds in a lane. It would be very helpful if we could have a /retest command or something similar where only failed lanes are re-run. That would be similar to how it is handled in Kubernetes. Right now it is an all-or-nothing thing. What I would expect, is that it is still possible to see the test history somewhere then (e.g. the first two attempts where it failed and then the third one where it succeeds). Best Regards, Roman -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/AUPNMQZABVVELFDSNY5XZTRDKFW2DOLC/
[JIRA] (OVIRT-2609) stdci style reports sometimes disappear pretty fast
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38445#comment-38445 ] Roman Mohr commented on OVIRT-2609: --- [~bkor...@redhat.com] you see them because I triggered them today again. > stdci style reports sometimes disappear pretty fast > --- > > Key: OVIRT-2609 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2609 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL >Reporter: Roman Mohr >Assignee: infra > > Can there be a SLA defined for how long we can see test results until they > get removed? > It does not have to be like on travis (where I can still see all my build > logs from years ago), but at least a predictable period would be nice. The > PR in [1] did for instance not have the results anymore from 5 days ago. > Thanks, > Roman > [1] https://github.com/kubevirt/kubevirt/pull/1744 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/SBD52AZR7SBNVPLSEUHQPTJOBREREIIE/
[JIRA] (OVIRT-2609) stdci style reports sometimes disappear pretty fast
Roman Mohr created OVIRT-2609: - Summary: stdci style reports sometimes disappear pretty fast Key: OVIRT-2609 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2609 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra Can there be a SLA defined for how long we can see test results until they get removed? It does not have to be like on travis (where I can still see all my build logs from years ago), but at least a predictable period would be nice. The PR in [1] did for instance not have the results anymore from 5 days ago. Thanks, Roman [1] https://github.com/kubevirt/kubevirt/pull/1744 -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/7KMWL75WL6U6W66WRZHGD4FAUFOMXVYO/
[JIRA] (OVIRT-2556) kubevirt test runs and nested docker issue
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38377#comment-38377 ] Roman Mohr commented on OVIRT-2556: --- Here is another one: https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2610//artifact/check-patch.windows2016-release.el7.x86_64/mock_logs/script/stdout_stderr.log > kubevirt test runs and nested docker issue > -- > > Key: OVIRT-2556 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2556 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL >Reporter: Roman Mohr >Assignee: infra > > Hi, > we see a lot of tests which fail with during the setup [1] : > ``` > /usr/bin/docker-current: Error response from daemon: grpc: the > connection is unavailable. > time="2018-10-23T07:17:55Z" level=error msg="error getting events from > daemon: context canceled" > ``` > It looks like the docker daemon may not run properly. > Best Regards, > Roman > [1] > https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2344//artifact/check-patch.openshift-3.10-crio-release.el7.x86_64/mock_logs/script/stdout_stderr.log -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/M5L3KFV2YF4YJLMPRAJ3P2WFYECS3MYS/
[JIRA] (OVIRT-2556) kubevirt test runs and nested docker issue
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Mohr updated OVIRT-2556: -- Resolution: Fixed Status: Done (was: To Do) > kubevirt test runs and nested docker issue > -- > > Key: OVIRT-2556 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2556 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL >Reporter: Roman Mohr >Assignee: infra > > Hi, > we see a lot of tests which fail with during the setup [1] : > ``` > /usr/bin/docker-current: Error response from daemon: grpc: the > connection is unavailable. > time="2018-10-23T07:17:55Z" level=error msg="error getting events from > daemon: context canceled" > ``` > It looks like the docker daemon may not run properly. > Best Regards, > Roman > [1] > https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2344//artifact/check-patch.openshift-3.10-crio-release.el7.x86_64/mock_logs/script/stdout_stderr.log -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/BA476FS5HIF2M655D57325HIOSGFZRXV/
[JIRA] (OVIRT-2593) How does stdci prevent regressions and proactively monitor the cluster?
Roman Mohr created OVIRT-2593: - Summary: How does stdci prevent regressions and proactively monitor the cluster? Key: OVIRT-2593 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2593 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra We want to go one step further with KubeVirt and sooner or later only merge when the tests are green (automatically). Therefore we want to ensure that this CI system is the right system for us and can be properly scaled, developed and operated. Apart from requirements like, automatically re-run tests and a merge-pools stability and QoS of the CI system are interesting for us. Some examples: * Sometimes jobs break with a system error shown in the logs (is that monitored and worked on?) * Sometimes things like "out-of-disk-space" show up. Is e.g. disk utilization proactively handled? * We had one issue where the docker installation was broken in a build-slot and all jobs stopped fast. As a consequence all following builds were scheduled there too. Is something like that monitored? * We repeatedly have issues, connecting to jenkins. It is extremely slow (not just Blue-Ocean-slow, really slow). Are such things monitored and alarms raised, countermeasures taken? * That did not happen for a while, but there were repeatedly bare-metal machines whithout kvm-nesting added to the cluster. Are there measures in place which prevent such regressions where the same issues happen multiple times? * How is the flexibility of the project ensured? Is it also tested and maintained in a sane fashion to allow proper evolution in time? Automated tests? Offline-testing of changes? And so on ... -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/TRLNUUGAPVCNULWBSKWEOOBFQPPPG7OH/
[JIRA] (OVIRT-2591) Add a distributed docker-cache
Roman Mohr created OVIRT-2591: - Summary: Add a distributed docker-cache Key: OVIRT-2591 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2591 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra What? If CI builds get heavy and things are running inside containers, I expect that the CI system proactively tries to optimize when it can. Since the CI system provides the docker installation, I would expect that under some conditions, it automatically puts heavy docker builds in a distributed cache in the cluster. Examples on how this can achieved are listed in [1] and [2]. Why? Dockerfiles have the advantage that we can isolate our biuld-steps in a Dockerfile. This gives reproducibility, but also means that e.g. curl downloads or RPM installs are not visible for the CI system. Therefore it is beneficial for the CI system and the user (more speed and less utilization), to put docker images with their build chain into a distributed cache and pre-fetch the cache into the docker cache of the build slot. Pre-fetching based on e.g. gibhub project probably makes sense. [1] https://runnable.com/blog/distributing-docker-cache-across-hosts [2] https://blog.codeship.com/building-a-remote-caching-system/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/NW7R5UI4IN4REREKUWJUZSXWULI5ZXNS/
[JIRA] (OVIRT-2592) Allow caching directories in the datacenter
Roman Mohr created OVIRT-2592: - Summary: Allow caching directories in the datacenter Key: OVIRT-2592 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2592 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra What? Sometimes jobs create huge artifacts or need to download a lot in order start building. For instance Maven, glide or bazel download a lot before they can build. These tools also include their own checks to ensure that the content of a cached folder is in-sync. It is helpful if people can specify directories to cache. Normally it makes sense to have options to allow a cache-per-build-branch. When a PR is merged into this branch the cache from that branch is used. There are very rare conditions where it is needed to clear such a cache. A UI-Button to do so is helpful. Just to higlight the difference to e.g. container whitelist: This is about caching in the cluster, not in a build-slot. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/Z3QPJEHBIAH3QBTRHNKW5KVEE2SVEKXN/
[JIRA] (OVIRT-2590) Cache Docker images in the datacenter
Roman Mohr created OVIRT-2590: - Summary: Cache Docker images in the datacenter Key: OVIRT-2590 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2590 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra What? As a user, I expect that I don't have to care about caching to speed up builds for the good of the CI system itself. Right now there exists a whitelist for docker images, which will not be remove from the build slot after the build. Instead of that I expect a clean build environment and that in general all images which I regularly use are cached in the cluster via e.g. a pull-through-cache [1]. Why? 1) Caching in a build slot is not very effective. CI runs do really-a-lot of almost identical things in a small time-window (e.g. days). If caching happens in the build-slot and many slots are present, then the cache utilization will be very low. 2) Whitelisting docker images extra for a slot where the registry runs in, is very error prone and since it is not cached across the cluster it is also very intransparent what the clear benefit for the user is. Especially when thinking about scaling a CI system, that seems to leak internal optimizations to the user. Fast builds are twice as important for the CI system than they are for the users (by default faster and lower utilization is always better than asking people to optimize on their side). [1] https://docs.docker.com/registry/recipes/mirror/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100095) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/ARXTBMT275LJ5VY26ZLGQG2ZWH63MPI2/
[JIRA] (OVIRT-2556) kubevirt test runs and nested docker issue
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38276#comment-38276 ] Roman Mohr commented on OVIRT-2556: --- the problem seems to be resolved for now. > kubevirt test runs and nested docker issue > -- > > Key: OVIRT-2556 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2556 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL >Reporter: Roman Mohr >Assignee: infra > > Hi, > we see a lot of tests which fail with during the setup [1] : > ``` > /usr/bin/docker-current: Error response from daemon: grpc: the > connection is unavailable. > time="2018-10-23T07:17:55Z" level=error msg="error getting events from > daemon: context canceled" > ``` > It looks like the docker daemon may not run properly. > Best Regards, > Roman > [1] > https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2344//artifact/check-patch.openshift-3.10-crio-release.el7.x86_64/mock_logs/script/stdout_stderr.log -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100094) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/6D47NKUUV3F5IVKF2A5AFO2WTK6VROA2/
[JIRA] (OVIRT-2556) kubevirt test runs and nested docker issue
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38263#comment-38263 ] Roman Mohr commented on OVIRT-2556: --- Ok, let me see if it looks better now. For reference here a very bad run https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2347/artifact/ci_build_summary.html from https://github.com/kubevirt/kubevirt/pull/1627. Retriggered test runs there now. > kubevirt test runs and nested docker issue > -- > > Key: OVIRT-2556 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2556 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL >Reporter: Roman Mohr >Assignee: infra > > Hi, > we see a lot of tests which fail with during the setup [1] : > ``` > /usr/bin/docker-current: Error response from daemon: grpc: the > connection is unavailable. > time="2018-10-23T07:17:55Z" level=error msg="error getting events from > daemon: context canceled" > ``` > It looks like the docker daemon may not run properly. > Best Regards, > Roman > [1] > https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2344//artifact/check-patch.openshift-3.10-crio-release.el7.x86_64/mock_logs/script/stdout_stderr.log -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100094) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/DRR52IJUFGCHDBWKVO53ES7ZRK7NBNGI/
[JIRA] (OVIRT-2556) kubevirt test runs and nested docker issue
Roman Mohr created OVIRT-2556: - Summary: kubevirt test runs and nested docker issue Key: OVIRT-2556 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2556 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra Hi, we see a lot of tests which fail with during the setup [1] : ``` /usr/bin/docker-current: Error response from daemon: grpc: the connection is unavailable. time="2018-10-23T07:17:55Z" level=error msg="error getting events from daemon: context canceled" ``` It looks like the docker daemon may not run properly. Best Regards, Roman [1] https://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2344//artifact/check-patch.openshift-3.10-crio-release.el7.x86_64/mock_logs/script/stdout_stderr.log -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100094) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/QD5EBG3HVH3OSKHHYFZR5TTPUS7XPCFW/
[JIRA] (OVIRT-2506) Accessing logs is sometimes extremely slow even without blueocean
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=38112#comment-38112 ] Roman Mohr commented on OVIRT-2506: --- [~eedri] not right now. > Accessing logs is sometimes extremely slow even without blueocean > - > > Key: OVIRT-2506 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2506 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Components: Jenkins Master >Reporter: Roman Mohr >Assignee: infra > > Hi, > With the switch from blueocean to the text-based build summary in > kubevirt/kubevirt, in general accessing works much better. Still > especially in the morning hours it can take a long time to access the > logs. > Can it be that the build summary and the logs are still served by > jenkins? If yes, would it help to copied out/cache/serve the build > logs via a dedicated webserver? > Best Regards, > Roman -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100092) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/I2EV3RTHSJCYBLOGAXZPDTDSC7R2GOYR/
[JIRA] (OVIRT-2506) Accessing logs is sometimes extremely slow even without blueocean
Roman Mohr created OVIRT-2506: - Summary: Accessing logs is sometimes extremely slow even without blueocean Key: OVIRT-2506 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2506 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra Hi, With the switch from blueocean to the text-based build summary in kubevirt/kubevirt, in general accessing works much better. Still especially in the morning hours it can take a long time to access the logs. Can it be that the build summary and the logs are still served by jenkins? If yes, would it help to copied out/cache/serve the build logs via a dedicated webserver? Best Regards, Roman -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100092) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/6MSESX4DDQICQURQWPUD2XL5TPLJNIXS/
[JIRA] (OVIRT-2485) shift.ovirt.org tls verification does not seem to work
Roman Mohr created OVIRT-2485: - Summary: shift.ovirt.org tls verification does not seem to work Key: OVIRT-2485 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2485 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infra Hi, If I expose an app on shift.ovirt.org via a tls endpoint, I get public urls like this: https://kubevirt-prow.apps.ovirt.org/hook. I can also use them e.g. on github for webhook, however I have to disable tls verification. For instance github gives me otherwise: We couldn’t deliver this payload: Peer certificate cannot be authenticated with given CA certificates Should there be a verifyable certificate? Best Regards, Roman -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100091) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/L7FJ3A24NMOLBEZYOFUUZAPRQIFPH7IS/
[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=35716#comment-35716 ] 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) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[JIRA] (OVIRT-1868) Allow engineers to write Jenkinsfiles
[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[JIRA] (OVIRT-1867) Allow embedded secrets inside the source repo for CI
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) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
