OST failing in 000_check_repo_closure
I tried to run OST on current basic-suite-master and it fails in 000_check_repo_closure. Is it only my local problem or is there something broken? How can I get OST running again? ## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/lago/ovirt-system-tests/basic-suite-master/reposync-config.repo_repoclosure', '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master-snapshot-static-el7', '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools-testing-el7', '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. ## Exist status: 1 ## Output: Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 12 centos-base-el7 centos-extras-el7 centos-kvm-common-el7 centos-opstools-testing-el7 centos-ovirt-4.0-el7 centos-updates-el7 copr-sac-gdeploy-el7 epel-el7 glusterfs-3.10-el7 internal_repo ovirt-master-snapshot-static-el7 ovirt-master-tested-el7 Num Packages in Repos: 37128 package: cockpit-ostree-138-1.el7.x86_64 from internal_repo unresolved deps: /usr/libexec/rpm-ostreed package: python2-botocore-1.4.43-1.el7.noarch from internal_repo unresolved deps: python-dateutil >= 0:2.1 Thanks, Milan
Hi, The same test is working in the experimental flow, so looks like a local issue. Are you using the most up to date master branch of ost? On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I tried to run OST on current basic-suite-master and it fails in 000_check_repo_closure. Is it only my local problem or is there something broken? How can I get OST running again?
## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ lago/ovirt-system-tests/basic-suite-master/reposync-config.repo_repoclosure', '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master-snapshot-static-el7', '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools-testing-el7', '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. ## Exist status: 1 ## Output: Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 12 centos-base-el7 centos-extras-el7 centos-kvm-common-el7 centos-opstools-testing-el7 centos-ovirt-4.0-el7 centos-updates-el7 copr-sac-gdeploy-el7 epel-el7 glusterfs-3.10-el7 internal_repo ovirt-master-snapshot-static-el7 ovirt-master-tested-el7 Num Packages in Repos: 37128 package: cockpit-ostree-138-1.el7.x86_64 from internal_repo unresolved deps: /usr/libexec/rpm-ostreed package: python2-botocore-1.4.43-1.el7.noarch from internal_repo unresolved deps: python-dateutil >= 0:2.1
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- DANIEL BELENKY Associate sw engineer RHEV DEVOPS Red Hat Israel <https://www.redhat.com/> dbelenky@redhat.com IRC: #rhev-integ, #rhev-dev <https://red.ht/sig>
Daniel Belenky <dbelenky@redhat.com> writes:
The same test is working in the experimental flow, so looks like a local issue. Are you using the most up to date master branch of ost?
Yes, the latest version from git.
On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I tried to run OST on current basic-suite-master and it fails in 000_check_repo_closure. Is it only my local problem or is there something broken? How can I get OST running again?
## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ lago/ovirt-system-tests/basic-suite-master/reposync-config.repo_repoclosure', '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master-snapshot-static-el7', '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools-testing-el7', '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. ## Exist status: 1 ## Output: Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 12 centos-base-el7 centos-extras-el7 centos-kvm-common-el7 centos-opstools-testing-el7 centos-ovirt-4.0-el7 centos-updates-el7 copr-sac-gdeploy-el7 epel-el7 glusterfs-3.10-el7 internal_repo ovirt-master-snapshot-static-el7 ovirt-master-tested-el7 Num Packages in Repos: 37128 package: cockpit-ostree-138-1.el7.x86_64 from internal_repo unresolved deps: /usr/libexec/rpm-ostreed package: python2-botocore-1.4.43-1.el7.noarch from internal_repo unresolved deps: python-dateutil >= 0:2.1
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
can you please attach the lago log here? On Tue, Jun 27, 2017 at 2:21 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
The same test is working in the experimental flow, so looks like a local issue. Are you using the most up to date master branch of ost?
Yes, the latest version from git.
On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I tried to run OST on current basic-suite-master and it fails in 000_check_repo_closure. Is it only my local problem or is there something broken? How can I get OST running again?
## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ lago/ovirt-system-tests/basic-suite-master/reposync-config. repo_repoclosure', '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master- snapshot-static-el7', '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools- testing-el7', '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. ## Exist status: 1 ## Output: Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 12 centos-base-el7 centos-extras-el7 centos-kvm-common-el7 centos-opstools-testing-el7 centos-ovirt-4.0-el7 centos-updates-el7 copr-sac-gdeploy-el7 epel-el7 glusterfs-3.10-el7 internal_repo ovirt-master-snapshot-static-el7 ovirt-master-tested-el7 Num Packages in Repos: 37128 package: cockpit-ostree-138-1.el7.x86_64 from internal_repo unresolved deps: /usr/libexec/rpm-ostreed package: python2-botocore-1.4.43-1.el7.noarch from internal_repo unresolved deps: python-dateutil >= 0:2.1
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- DANIEL BELENKY Associate sw engineer RHEV DEVOPS Red Hat Israel <https://www.redhat.com/> dbelenky@redhat.com IRC: #rhev-integ, #rhev-dev <https://red.ht/sig>
Daniel Belenky <dbelenky@redhat.com> writes:
can you please attach the lago log here?
Here it is:
On Tue, Jun 27, 2017 at 2:21 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
The same test is working in the experimental flow, so looks like a local issue. Are you using the most up to date master branch of ost?
Yes, the latest version from git.
On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I tried to run OST on current basic-suite-master and it fails in 000_check_repo_closure. Is it only my local problem or is there something broken? How can I get OST running again?
## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ lago/ovirt-system-tests/basic-suite-master/reposync-config. repo_repoclosure', '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master- snapshot-static-el7', '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools- testing-el7', '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. ## Exist status: 1 ## Output: Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 12 centos-base-el7 centos-extras-el7 centos-kvm-common-el7 centos-opstools-testing-el7 centos-ovirt-4.0-el7 centos-updates-el7 copr-sac-gdeploy-el7 epel-el7 glusterfs-3.10-el7 internal_repo ovirt-master-snapshot-static-el7 ovirt-master-tested-el7 Num Packages in Repos: 37128 package: cockpit-ostree-138-1.el7.x86_64 from internal_repo unresolved deps: /usr/libexec/rpm-ostreed package: python2-botocore-1.4.43-1.el7.noarch from internal_repo unresolved deps: python-dateutil >= 0:2.1
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
I've sent a workaround patch [1] that supposes to fix this. Please notice that I'm still testing it on the different suites in OST (basic_suite_master is working). You can try to run OST locally with this patch [1] https://gerrit.ovirt.org/#/c/78710/1 On Tue, Jun 27, 2017 at 2:35 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
can you please attach the lago log here?
Here it is:
On Tue, Jun 27, 2017 at 2:21 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
The same test is working in the experimental flow, so looks like a local issue. Are you using the most up to date master branch of ost?
Yes, the latest version from git.
On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I tried to run OST on current basic-suite-master and it fails in 000_check_repo_closure. Is it only my local problem or is there something broken? How can I get OST running again?
## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ lago/ovirt-system-tests/basic-suite-master/reposync-config. repo_repoclosure', '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master- snapshot-static-el7', '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools- testing-el7', '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. ## Exist status: 1 ## Output: Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 12 centos-base-el7 centos-extras-el7 centos-kvm-common-el7 centos-opstools-testing-el7 centos-ovirt-4.0-el7 centos-updates-el7 copr-sac-gdeploy-el7 epel-el7 glusterfs-3.10-el7 internal_repo ovirt-master-snapshot-static-el7 ovirt-master-tested-el7 Num Packages in Repos: 37128 package: cockpit-ostree-138-1.el7.x86_64 from internal_repo unresolved deps: /usr/libexec/rpm-ostreed package: python2-botocore-1.4.43-1.el7.noarch from internal_repo unresolved deps: python-dateutil >= 0:2.1
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- DANIEL BELENKY Associate sw engineer RHEV DEVOPS Red Hat Israel <https://www.redhat.com/> dbelenky@redhat.com IRC: #rhev-integ, #rhev-dev <https://red.ht/sig>
Daniel Belenky <dbelenky@redhat.com> writes:
I've sent a workaround patch [1] that supposes to fix this. Please notice that I'm still testing it on the different suites in OST (basic_suite_master is working). You can try to run OST locally with this patch
Yes, this workaround suppresses the problem, thank you.
On Tue, Jun 27, 2017 at 2:35 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
can you please attach the lago log here?
Here it is:
On Tue, Jun 27, 2017 at 2:21 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
The same test is working in the experimental flow, so looks like a local issue. Are you using the most up to date master branch of ost?
Yes, the latest version from git.
On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
I tried to run OST on current basic-suite-master and it fails in 000_check_repo_closure. Is it only my local problem or is there something broken? How can I get OST running again?
## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ lago/ovirt-system-tests/basic-suite-master/reposync-config. repo_repoclosure', '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master- snapshot-static-el7', '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools- testing-el7', '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. ## Exist status: 1 ## Output: Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 12 centos-base-el7 centos-extras-el7 centos-kvm-common-el7 centos-opstools-testing-el7 centos-ovirt-4.0-el7 centos-updates-el7 copr-sac-gdeploy-el7 epel-el7 glusterfs-3.10-el7 internal_repo ovirt-master-snapshot-static-el7 ovirt-master-tested-el7 Num Packages in Repos: 37128 package: cockpit-ostree-138-1.el7.x86_64 from internal_repo unresolved deps: /usr/libexec/rpm-ostreed package: python2-botocore-1.4.43-1.el7.noarch from internal_repo unresolved deps: python-dateutil >= 0:2.1
Thanks, Milan _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Works for me as well. On Tue, Jun 27, 2017 at 4:58 PM Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
I've sent a workaround patch [1] that supposes to fix this. Please notice that I'm still testing it on the different suites in OST (basic_suite_master is working). You can try to run OST locally with this patch
Yes, this workaround suppresses the problem, thank you.
On Tue, Jun 27, 2017 at 2:35 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
can you please attach the lago log here?
Here it is:
On Tue, Jun 27, 2017 at 2:21 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
The same test is working in the experimental flow, so looks like a local issue. Are you using the most up to date master branch of ost?
Yes, the latest version from git.
On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal < mzamazal@redhat.com> wrote:
> I tried to run OST on current basic-suite-master and it fails in > 000_check_repo_closure. Is it only my local problem or is there > something broken? How can I get OST running again? > > ## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ > lago/ovirt-system-tests/basic-suite-master/reposync-config. repo_repoclosure', > '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master- snapshot-static-el7', > '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates-el7', > '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', > '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', > '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools- testing-el7', > '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. > ## Exist status: 1 > ## Output: Reading in repository metadata - please wait.... > Checking Dependencies > Repos looked at: 12 > centos-base-el7 > centos-extras-el7 > centos-kvm-common-el7 > centos-opstools-testing-el7 > centos-ovirt-4.0-el7 > centos-updates-el7 > copr-sac-gdeploy-el7 > epel-el7 > glusterfs-3.10-el7 > internal_repo > ovirt-master-snapshot-static-el7 > ovirt-master-tested-el7 > Num Packages in Repos: 37128 > package: cockpit-ostree-138-1.el7.x86_64 from internal_repo > unresolved deps: > /usr/libexec/rpm-ostreed > package: python2-botocore-1.4.43-1.el7.noarch from internal_repo > unresolved deps: > python-dateutil >= 0:2.1 > > Thanks, > Milan > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Thanks for the feedback Milan and Roy, I've also managed to successfully verify this change on all of the related suites. We've merged this change, so please update your local ost repo. On Tue, Jun 27, 2017 at 5:19 PM, Roy Golan <rgolan@redhat.com> wrote:
Works for me as well.
On Tue, Jun 27, 2017 at 4:58 PM Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
I've sent a workaround patch [1] that supposes to fix this. Please notice that I'm still testing it on the different suites in OST (basic_suite_master is working). You can try to run OST locally with this patch
Yes, this workaround suppresses the problem, thank you.
On Tue, Jun 27, 2017 at 2:35 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
can you please attach the lago log here?
Here it is:
On Tue, Jun 27, 2017 at 2:21 PM, Milan Zamazal <mzamazal@redhat.com> wrote:
Daniel Belenky <dbelenky@redhat.com> writes:
> The same test is working in the experimental flow, so looks like a local > issue. > Are you using the most up to date master branch of ost?
Yes, the latest version from git.
> On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal < mzamazal@redhat.com> wrote: > >> I tried to run OST on current basic-suite-master and it fails in >> 000_check_repo_closure. Is it only my local problem or is there >> something broken? How can I get OST running again? >> >> ## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/ >> lago/ovirt-system-tests/basic-suite-master/reposync-config. repo_repoclosure', >> '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master- snapshot-static-el7', >> '--lookaside=glusterfs-3.10-el7', '--lookaside=centos-updates- el7', >> '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7', >> '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7', >> '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools- testing-el7', >> '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo']. >> ## Exist status: 1 >> ## Output: Reading in repository metadata - please wait.... >> Checking Dependencies >> Repos looked at: 12 >> centos-base-el7 >> centos-extras-el7 >> centos-kvm-common-el7 >> centos-opstools-testing-el7 >> centos-ovirt-4.0-el7 >> centos-updates-el7 >> copr-sac-gdeploy-el7 >> epel-el7 >> glusterfs-3.10-el7 >> internal_repo >> ovirt-master-snapshot-static-el7 >> ovirt-master-tested-el7 >> Num Packages in Repos: 37128 >> package: cockpit-ostree-138-1.el7.x86_64 from internal_repo >> unresolved deps: >> /usr/libexec/rpm-ostreed >> package: python2-botocore-1.4.43-1.el7.noarch from internal_repo >> unresolved deps: >> python-dateutil >= 0:2.1 >> >> Thanks, >> Milan >> _______________________________________________ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >>
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- DANIEL BELENKY Associate sw engineer RHEV DEVOPS Red Hat Israel <https://www.redhat.com/> dbelenky@redhat.com IRC: #rhev-integ, #rhev-dev <https://red.ht/sig>
participants (3)
-
Daniel Belenky -
Milan Zamazal -
Roy Golan