[JIRA] (OVIRT-900) Re: Rebase over other author's patch cannot be pushed to gerrit
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-900?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-900:
-------------------------------------------------
[~sbendavi(a)redhat.com] maybe missing 'forge author identity' permission missing to all 'master branch maintaines'?
> Re: Rebase over other author's patch cannot be pushed to gerrit
> ---------------------------------------------------------------
>
> Key: OVIRT-900
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-900
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Barak Korren
> Assignee: Shlomo Ben David
>
> Forwarding to infra-support.
> On 1 December 2016 at 18:03, Yaniv Bronheim <ybronhei(a)redhat.com> wrote:
> > Not sure since when it was changed, but I noticed that I can't push patches
> > if I'm not the author
> >
> > Counting objects: 50, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (50/50), done.
> > Writing objects: 100% (50/50), 36.66 KiB | 0 bytes/s, done.
> > Total 50 (delta 34), reused 0 (delta 0)
> > remote: Resolving deltas: 100% (34/34)
> > remote: Processing changes: refs: 1, done
> > remote:
> > remote: ERROR: In commit db14ec7c1555a9eb37a0fb931bbb4ebdfc674bb4
> > remote: ERROR: author email address rnachimu(a)redhat.com
> > remote: ERROR: does not match your user account.
> > remote: ERROR:
> > remote: ERROR: The following addresses are currently registered:
> > remote: ERROR: bronhaim(a)gmail.com
> > remote: ERROR: ybronhei(a)redhat.com
> > remote: ERROR:
> > remote: ERROR: To register an email address, please visit:
> > remote: ERROR: https://gerrit.ovirt.org/#/settings/contact
> > remote:
> > remote:
> > To ssh://ybronhei@gerrit.ovirt.org:29418/vdsm
> > ! [remote rejected] HEAD -> refs/for/master (invalid author)
> > error: failed to push some refs to
> > 'ssh://ybronhei@gerrit.ovirt.org:29418/vdsm'
> >
> > We must have permissions to do that, this is part of the rebasing part, and
> > I think its fine to fix patches on behalf of someone else.. but its not the
> > best practice for reviewing.
> > anyway, please undo this change, unless its something that related only to
> > my env.. let me know
> >
> > Thanks
> >
> > --
> > Yaniv Bronhaim.
> >
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> --
> Barak Korren
> bkorren(a)redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
--
This message was sent by Atlassian JIRA
(v1000.606.0#100023)
8 years, 1 month
[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira... ]
Barak Korren commented on OVIRT-902:
------------------------------------
[~ykaul] The packages install is done by mock itself during the setup of the chroot - so could probably be sped up.
All the rest:
* The pip stuff
* The autogen w/o locale
* other package installs
All come from inside check_patch.sh (from vdsm repo) so do not belong on this ticket.
Having said that, yum in the mock env is running through oVirt's proxy - so not really going to the internet (pre-post install script still takt time though which is why the mock setup is long).
We could probably find one way or another to make pip go through the proxy too to make it a little faster (Maybe export the "_http_proxy_" env var in to the mock env .to make scripts able to leverage it).
Looking deeper into our scripts, this can be found in mock_cleanup.sh:
{code}
# remove mock system cache, we will setup proxies to do the caching and this
# takes lots of space between runs
shopt -u nullglob
sudo rm -Rf /var/cache/mock/*
{code}
We probably need need remove that before we can gain any speed ups. But we must heed David's warning and make sure we zap the caches frequently enough so we don't fill up the slaves.
> Speed up mock_runner.sh setup time by using caches.
> ---------------------------------------------------
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
> Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build scripts, so they should be safe to use.
--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
8 years, 1 month
[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-902:
-------------------------------------------------
I think we see the slowness also on experimental flows, same actions which takes a few seconds w/o mock takes 2 min when running with mock runner.
So we should probably give priority to checking the caching options.
> Speed up mock_runner.sh setup time by using caches.
> ---------------------------------------------------
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
> Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build scripts, so they should be safe to use.
--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
8 years, 1 month
[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.
by Yaniv Kaul (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira... ]
Yaniv Kaul commented on OVIRT-902:
----------------------------------
1. I'm not sure if it's here or requires a different ticket, but this is SLOW (taken from http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5101/con... ):
*00:01:28.338* INFO: installing package(s): autoconf automake gdb git libguestfs-tools-c libselinux-python3 libvirt-python3 m2crypto make mom openvswitch policycoreutils-python PyYAML python-blivet python-coverage python2-decorator python-devel python-inotify python-ioprocess python-mock python-netaddr python-pthreading python-setuptools python-six python-requests python3-decorator python3-netaddr python3-nose python3-six python3-yaml rpm-build sanlock-python sudo yum yum-utils
*00:03:48.999* INFO: None
2:20 to install packages, is VERY slow.
2. Then there are the pip stuff - which probably are also going somewhere off to the 'net:
00:03:52.839 + easy_install pip
...
00:03:53.401 + pip install -U tox==2.1.1
...
00:03:55.843 Downloading pluggy-0.3.1-py2.py3-none-any.whl
00:03:55.868 Installing collected packages: virtualenv, py, pluggy, tox
00:03:56.223 Successfully installed pluggy-0.3.1 py-1.4.31 tox-2.1.1 virtualenv-15.1.0
So only 4 seconds, but probably not needed at all.
3. Why not set locale?
00:03:56.670 + ./autogen.sh --system --enable-hooks --enable-vhostmd
00:03:56.678 perl: warning: Setting locale failed.
00:03:56.678 perl: warning: Please check that your locale settings:
00:03:56.679 LANGUAGE = (unset),
00:03:56.679 LC_ALL = (unset),
00:03:56.679 LANG = "en_US.UTF-8"
4. The 5 seconds here are probably due to slow storage!
00:04:05.096 client/Makefile.am:23: installing 'build-aux/py-compile'
00:04:10.239 Running ./configure with --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib64 --enable-hooks --enable-vhostmd
5. This is also going out to the Internet?
00:04:14.989 + debuginfo-install -y python
...
00:04:30.879 glibc-debuginfo-common.x86_64 0:2.23.1-11.fc24
6. Again some more deps:
00:05:23.621 tox -e tests
00:05:23.912 tests create: /home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/.tox/tests
00:05:29.991 tests installdeps: nose==1.3.7
7. it's not clear if the nose tests are running in parallel. Is that supported by VDSM tests?
8. Not sure what is going on here:
00:09:34.017 + coverage html -d /home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/exported-artifacts/htmlcov
00:09:49.213 + popd
00:09:49.213 ~
00:09:49.213 + shopt -s extglob
00:09:49.213 + git diff-tree --no-commit-id --name-only -r HEAD
00:09:49.213 + egrep --quiet 'vdsm.spec.in|Makefile.am'
00:19:07.994 Took 915 seconds
> Speed up mock_runner.sh setup time by using caches.
> ---------------------------------------------------
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
> Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build scripts, so they should be safe to use.
--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
8 years, 1 month
[JIRA] (OVIRT-903) master-to-master CI upgrade tests
by Yedidyah Bar David (oVirt JIRA)
Yedidyah Bar David created OVIRT-903:
----------------------------------------
Summary: master-to-master CI upgrade tests
Key: OVIRT-903
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-903
Project: oVirt - virtualization made easy
Issue Type: By-EMAIL
Reporter: Yedidyah Bar David
Assignee: infra
Hi all,
Recently a patch to the engine [1] added a new package,
with a certain set of dependencies, which broke upgrade.
This is similar to [2] but for a new package.
CI wasn't affected, I think because of [3].
To make CI test such flows, we should have a job that:
1. Builds, installs and sets up the version we want to test
2. Pushes a dummy change to the local git repo (to force
a new version), build the patched tree, create a yum repo
with the build and add it to yum.repos.d.
3. yum update
4. engine-setup
Another option is to revert [3], or to duplicate - have
both "upgrade current to self" and "upgrade latest snapshot
to current". The downside is that it will be checked later
than above plan - instead of in the same build, will only
be tested in the first build that uses the snapshot after
it was updated, and also will be misleading, as the reason
why that job failed will not be apparent (which was why
[3] was added).
Please handle. I can of course try to help. Best,
[1] https://gerrit.ovirt.org/66999
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
[3] https://gerrit.ovirt.org/67263
--
Didi
--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
8 years, 1 month
[JIRA] (OVIRT-901) bad mirror caused check-merged jobs to fail
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-901?page=com.atlassian.jira... ]
Barak Korren commented on OVIRT-901:
------------------------------------
One approach to setting up a mirror that never fails is to make it "transactional" by actually seyting up a whole new mirror every time you sync it and then create some kind of a meta-data file that point to where it is.
That way when a job starts running it just takes the latest meta-data file in it is guaranteed that the thing this file points to will never change while the job is running.
This doesn't mean that syncing the mirror will be slow, there are quite a few things we can do to make it fast:
* Use hardlinks - before running the mirror sync tool (reposync, repoman, rsync, etc.) copy the older mirror (by creating hardlinks so the copy is fast) to the new location.
* Use LVM snapshots - Always sync the mirror to the same place, but after the sync is done, create an LVM snapshot of that place, mount it and put the location it is mounted into as the path in the metadata file.
* Use a tool the has this kind of functionality built-in (Katallo/Pulp with content views)
> bad mirror caused check-merged jobs to fail
> -------------------------------------------
>
> Key: OVIRT-901
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-901
> Project: oVirt - virtualization made easy
> Issue Type: Bug
> Reporter: eyal edri [Administrator]
> Assignee: infra
>
> check-merged jobs fails on bad mirrors:
> If we can't defend ourselves from repomd.xml file errors, lets setup a mirror when we control the mirror sync and we can decide on the update times ( maybe even disable jenkins jobs when the update is running to avoid errors )
> http://jenkins.ovirt.org/job/repos_3.6_check-closure_el7_merged/103/console
> 07:35:30 Can't download or revert repomd.xml for check-epel-el7
> 07:35:30 Some dependencies may not be complete for this repository
> 07:35:30 Run as root to get all dependencies or use -t to enable a user temp cache
> 07:35:30 Checking Dependencies
> 07:35:30 failure: repodata/151a911cc4b434fcd135e243eec4a4f1d8c1943595a92e2bb838cda5f03577ff-primary.sqlite.xz from check-epel-el7: [Errno 256] No more mirrors to try.
> 07:35:30 http://mirror.switch.ch/ftp/mirror/epel/7/x86_64/repodata/151a911cc4b434f...: [Errno 14] HTTP Error 404 - Not Found
--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
8 years, 1 month
[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira... ]
Barak Korren updated OVIRT-902:
-------------------------------
Labels: mock mock_runner.sh standard-ci (was: )
> Speed up mock_runner.sh setup time by using caches.
> ---------------------------------------------------
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
> Labels: mock, mock_runner.sh, standard-ci
>
> We've already known that setting up mock takes a while, but mock has some built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build scripts, so they should be safe to use.
--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
8 years, 1 month
[JIRA] (OVIRT-902) Speed up mock_runner.sh setup time by using caches.
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-902?page=com.atlassian.jira... ]
Barak Korren updated OVIRT-902:
-------------------------------
Epic Link: OVIRT-400
> Speed up mock_runner.sh setup time by using caches.
> ---------------------------------------------------
>
> Key: OVIRT-902
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-902
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Reporter: Barak Korren
> Assignee: infra
> Priority: High
>
> We've already known that setting up mock takes a while, but mock has some built-in caching features that should allow us to speed this up.
> We need to ensure those features are enabled by mock_runner.sh. The mock options to look at are:
> * root_cache_enable
> * yum_cache_enable
> Both these options should be set to true in the mock chroot config file.
> We've been using these option downstream in minimead and the vdsm build scripts, so they should be safe to use.
--
This message was sent by Atlassian JIRA
(v1000.610.2#100023)
8 years, 1 month
