December 2016 - Infra - oVirt List Archives

[JIRA] (OVIRT-899) Create locking on experimental flow
by Gil Shinar (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-899?page=com.atlassian.jira.p… ] Gil Shinar reassigned OVIRT-899: -------------------------------- Assignee: Daniel Belenky (was: infra) > Create locking on experimental flow > ----------------------------------- > > Key: OVIRT-899 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-899 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Gil Shinar > Assignee: Daniel Belenky > > In order to make experimental flow atomic, we need to do as follows: > in deploy.sh script and in start_testing_latest.sh we need to add a loop in the beginning of each script that does the following: > *while 1: > do > is_locked=$((echo aaa > my.lock) 2> /dev/null || echo is locked) > if [[ -z $is_locked ]]; then > break > else > sleep 5 > fi > done* > Wrap the whole script with a trap so in the end if each script we will be able to remove my.lock no matter what happened. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-921) Smarter cache handling for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-921?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-921: ------------------------------- Labels: mock mock_runner.sh performance standard-ci (was: ) > Smarter cache handling for mock_runner.sh > ----------------------------------------- > > Key: OVIRT-921 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-921 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: mock, mock_runner.sh, performance, standard-ci > > We've improved our handing of mock caches in OVIRT-902, but it could be better. > Right now we're just deleting everything from {{mock_cleanup.sh}} every two days, but we could do things in a smarter and more refined way: > * Mock actually has two separate caches that could be handled separately: > *# The yum cache - Caches package that are installed in the chroot > *# The root cache - Keeps an archive of the whole chroot > * We can make the yum cache shared by all the chroots that use the same repos > * We can keep the yum cache for much longer since 'yum' will refresh it automatically. We can tune this from mock root config file: > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_age_days']}} > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_metadata_age_days']}} > * We can also control the chroot cache from the mock config file, this will allow us greated flexibility, like deciding that some chroots live longer: > ** {{config_opts\['plugin_conf']\['root_cache_opts']\['max_age_days']}} > * We can use a different compression algorithm for the chroot acche, this may yield better performance. > * We still need some cleanup in {{moch_cleanup.sh}} but only for chroot caches that ahvn't been in use for a long time. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-921) Smarter cache handling for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

Barak Korren created OVIRT-921: ---------------------------------- Summary: Smarter cache handling for mock_runner.sh Key: OVIRT-921 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-921 Project: oVirt - virtualization made easy Issue Type: Improvement Components: Jenkins Reporter: Barak Korren Assignee: infra We've improved our handing of mock caches in OVIRT-902, but it could be better. Right now we're just deleting everything from {{mock_cleanup.sh}} every two days, but we could do things in a smarter and more refined way: * Mock actually has two separate caches that could be handled separately: *# The yum cache - Caches package that are installed in the chroot *# The root cache - Keeps an archive of the whole chroot * We can make the yum cache shared by all the chroots that use the same repos * We can keep the yum cache for much longer since 'yum' will refresh it automatically. We can tune this from mock root config file: ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_age_days']}} ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_metadata_age_days']}} * We can also control the chroot cache from the mock config file, this will allow us greated flexibility, like deciding that some chroots live longer: ** {{config_opts\['plugin_conf']\['root_cache_opts']\['max_age_days']}} * We can use a different compression algorithm for the chroot acche, this may yield better performance. * We still need some cleanup in {{moch_cleanup.sh}} but only for chroot caches that ahvn't been in use for a long time. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-921) Smarter cache handling for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-921?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-921: ------------------------------- Epic Link: OVIRT-400 > Smarter cache handling for mock_runner.sh > ----------------------------------------- > > Key: OVIRT-921 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-921 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > Labels: mock, mock_runner.sh, performance, standard-ci > > We've improved our handing of mock caches in OVIRT-902, but it could be better. > Right now we're just deleting everything from {{mock_cleanup.sh}} every two days, but we could do things in a smarter and more refined way: > * Mock actually has two separate caches that could be handled separately: > *# The yum cache - Caches package that are installed in the chroot > *# The root cache - Keeps an archive of the whole chroot > * We can make the yum cache shared by all the chroots that use the same repos > * We can keep the yum cache for much longer since 'yum' will refresh it automatically. We can tune this from mock root config file: > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_age_days']}} > ** {{config_opts\['plugin_conf']\['yum_cache_opts']\['max_metadata_age_days']}} > * We can also control the chroot cache from the mock config file, this will allow us greated flexibility, like deciding that some chroots live longer: > ** {{config_opts\['plugin_conf']\['root_cache_opts']\['max_age_days']}} > * We can use a different compression algorithm for the chroot acche, this may yield better performance. > * We still need some cleanup in {{moch_cleanup.sh}} but only for chroot caches that ahvn't been in use for a long time. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-830) Vdsm lost its "Forge Author" permission?
by Shlomo Ben David (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-830?page=com.atlassian.jira.p… ] Shlomo Ben David reassigned OVIRT-830: -------------------------------------- Assignee: Shlomo Ben David (was: infra) > Vdsm lost its "Forge Author" permission? > ---------------------------------------- > > Key: OVIRT-830 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-830 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: Shlomo Ben David > > Until recently, any registered user could take on somebody else's change, > and post a new patchset to it. > It's very useful when someone wants to fix a typo in someone else's > code, or when we need to take on a work of a sick/vacating developer. > Please amend this. I'm not 100% sure, but it could be fix by setting > "Forge Author" on the vdsm project. > https://gerrit-review.googlesource.com/Documentation/access-control.html#ca… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-907) Add CI for mock_runner.sh
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-907?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-907: ------------------------------------ This was partially done here: https://gerrit.ovirt.org/#/c/67802 Still missing: * Other arch tests (We will need to resolve OVIRT-914 for this) * More tests (For example verify that all packages from the "{{*.packages}}" file were installed. > Add CI for mock_runner.sh > ------------------------- > > Key: OVIRT-907 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-907 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > We have some CI jobs running on our "Jenkins" repo right now. Those jobs mostly check YAML, but they are also useful for checking changes to mock_runner.sh because they are running inside it. However: > # These jobs do a full YAML check even when it is not needed. > # We're not actually checking mock_runner.sh for all the platforms it simulates. > We've already seem some regressions happen in the CI system because we don't have enough tests for mock_runner.sh > This ticket is for creating good CI coverage for mock_runner.sh, all that is needed to be done in practice is make some changes to the check_patch.sh script and the YAML so that: > * YAML checking is skipped if no JJB-related changes were done > * Various features of mock_runner like the installation of packages for the *.packages files are checked. > * The tests are ran for all platforms that mock_runner.sh supports. -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-830) Vdsm lost its "Forge Author" permission?
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-830?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-830: -------------------------------------------- Resolution: Fixed Status: Done (was: To Do) permission updated to work for all registered users. > Vdsm lost its "Forge Author" permission? > ---------------------------------------- > > Key: OVIRT-830 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-830 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Until recently, any registered user could take on somebody else's change, > and post a new patchset to it. > It's very useful when someone wants to fix a typo in someone else's > code, or when we need to take on a work of a sick/vacating developer. > Please amend this. I'm not 100% sure, but it could be fix by setting > "Forge Author" on the vdsm project. > https://gerrit-review.googlesource.com/Documentation/access-control.html#ca… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-828) ovirt-engine_master_check-patch-fc24-x86_64 failing
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-828?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-828: -------------------------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) job history is deleted already and didn't got a response on this ticket. feel free to open is issue persists. > ovirt-engine_master_check-patch-fc24-x86_64 failing > --------------------------------------------------- > > Key: OVIRT-828 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-828 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Greg Sheremeta > Assignee: infra > > http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc24-x86_64/68… > Doesn't appear related to the patch. > > > > 17:52:04 Finish: cleaning yum metadata > > 17:52:04 Mock Version: 1.2.21 > > 17:52:04 INFO: Mock Version: 1.2.21 > > 17:52:04 Start: yum install > > 17:52:09 ERROR: Command failed. See logs for output. > > 17:52:09 # /usr/bin/yum-deprecated --installroot > > /var/lib/mock/fedora-24-x86_64-a84bda050a5e85bcae66e67894bf5f93-17376/root/ > > --releasever 24 install @buildsys-build --setopt=tsflags=nocontexts > > 17:52:09 Init took 6 seconds > Thanks, > Greg > -- > Greg Sheremeta, MBA > Red Hat, Inc. > Sr. Software Engineer > gshereme(a)redhat.com -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-920) Add a standard-CI job and button "build-scratch-artifacts"
by eyal edri [Administrator] (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-920?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-920: ------------------------------------------------- the hooks triggering is totally different system ( gerrit hooks internal ) and yes, the comments are not functional and we should probably fix them. What I suggested is to use the Jenkins Gerrit Trigger capabilities, so it won't suffer from the same problem. > Add a standard-CI job and button "build-scratch-artifacts" > ---------------------------------------------------------- > > Key: OVIRT-920 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-920 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Yedidyah Bar David > Assignee: infra > > Hi, > I think it will be useful to have an option to very easily (such as > pressing a button in gerrit) to do a full build of a project, > similarly to current build-artifacts, but for a pending patch - so it > will not be collected by any publisher, and will keep its artifacts > for a short time (say, 2 days). > This will allow to use these artifacts for manual tests, perhaps > longer than check-patch, in case a developer wants to do them. > -- > Didi -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0

[JIRA] (OVIRT-904) False CI-1 due to unreachable copr-be.cloud.fedoraproject.org
by Barak Korren (oVirt JIRA) 08 Dec '16

08 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-904?page=com.atlassian.jira.p… ] Barak Korren edited comment on OVIRT-904 at 12/8/16 10:36 AM: -------------------------------------------------------------- [~gshereme(a)redhat.com] are you doing that manually, or do you have some automation built around it? I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project. Perhaps make travis run the build in Copr, and then take the result and push it to GitHub's artifact storage? Another possibility is to use [BinTray|https://bintray.com/] We might eventually mirror this in oVirt infra to make CI resilient to changes there (see OVIRT-575) was (Author: bkorren(a)redhat.com) [~gshereme(a)redhat.com] are you dong that manually, or do you have some automation built around it? I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project. Perhaps make travis run the build in Copr, and then take the result and push it to GitHub's artifact storage? Another possibility is to use [BinTray|https://bintray.com/] We might eventually mirror this in oVirt infra to make CI resilient to changes there (see OVIRT-575) > False CI-1 due to unreachable copr-be.cloud.fedoraproject.org > ------------------------------------------------------------- > > Key: OVIRT-904 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-904 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Many patches on > https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to > failure: repodata/repomd.xml from patternfly: [Errno 256] No more > mirrors to try. > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-…: > [Errno 14] curl#7 - "Failed connect to > copr-be.cloud.fedoraproject.org:80; No route to host" > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-… -- This message was sent by Atlassian JIRA (v1000.620.0#100023)

1 0