Re: [ovirt-devel] jobs failure due to same package version with different checksum

2018-10-23 Thread Maor Lipchuk
Thanks Dafna,

I will do that, will update the thread once it will be fixed.

Thanks,
Maor

On Tue, Oct 23, 2018 at 5:29 PM Dafna Ron  wrote:

> Hi,
>
> We have been having failure in master for different projects due to
> package ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm.
>
> It seems the package had been changed without a new version set which
> means we have the same exact package with two different checksum (one in
> 4.2 and one in master):
>
> ovirt-4.2:
>
> [dron@resources02 noarch]$ md5sum
> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
> 07b2c6c7ef94e48be3c197e2a1d45d81
> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
>
> ovirt-master:
>
> [dron@resources02 noarch]$ md5sum
> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
> f6b2e88ae07b64d5071696ade510d961
> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
>
> Can you please create a new package with version change to solve
> this problem?
>
> Thanks,
> Dafna
>
> ___
> Devel mailing list -- de...@ovirt.org
> To unsubscribe send an email to devel-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/de...@ovirt.org/message/NT5I63AQQXJOWZPW4IIKDTROSY2KJTQV/
>
___
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/F3CW3VI72AS4RJU7HCY476LW637E2J5N/


Re: [ovirt-devel] jobs failure due to same package version with different checksum

2018-10-24 Thread Maor Lipchuk
Fixing patch has been merged:
   https://github.com/oVirt/ovirt-ansible-disaster-recovery/pull/62
Thank you Ondra and Dafna

On Wed, Oct 24, 2018 at 1:20 AM Maor Lipchuk  wrote:

> Thanks Dafna,
>
> I will do that, will update the thread once it will be fixed.
>
> Thanks,
> Maor
>
> On Tue, Oct 23, 2018 at 5:29 PM Dafna Ron  wrote:
>
>> Hi,
>>
>> We have been having failure in master for different projects due to
>> package ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm.
>>
>> It seems the package had been changed without a new version set which
>> means we have the same exact package with two different checksum (one in
>> 4.2 and one in master):
>>
>> ovirt-4.2:
>>
>> [dron@resources02 noarch]$ md5sum
>> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
>> 07b2c6c7ef94e48be3c197e2a1d45d81
>> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
>>
>> ovirt-master:
>>
>> [dron@resources02 noarch]$ md5sum
>> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
>> f6b2e88ae07b64d5071696ade510d961
>> ovirt-ansible-disaster-recovery-1.1.2-1.el7.noarch.rpm
>>
>> Can you please create a new package with version change to solve
>> this problem?
>>
>> Thanks,
>> Dafna
>>
>> ___
>> Devel mailing list -- de...@ovirt.org
>> To unsubscribe send an email to devel-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/de...@ovirt.org/message/NT5I63AQQXJOWZPW4IIKDTROSY2KJTQV/
>>
>
___
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/JIAHC4VYZXCQ634HQZWI4RGIL673OLXN/


problem to see draft patches in gerrit.ovirt.org

2016-11-22 Thread Maor Lipchuk
Hi all,

There is a permission issue in gerrit.ovirt.org that blocks seeing draft
patches.
Once I try to see a draft patch I'm getting the following message:
 "The page you requested was not found, or you do not have permission to
view this page."
Will appreciate your help.

Regards,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


CI ovirt-engine_master_upgrade-from-master_el7_created failing spontaniously

2016-11-23 Thread Maor Lipchuk
Hi all,

I'm not sure if this is a known issue but it seems
that ovirt-engine_master_upgrade-from-master_el7_created is failing almost
all the time.
I also see other patches than mine that fail on it.
Is there anything I can help with to make it fixed

Thanks,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Failing VDSM CI tests caused by connection refused.

2016-12-24 Thread Maor Lipchuk
*Hi,*


*I saw also few recent patches failing on the same error, looks like a
network issue:*


*22:02:51*  > git clean -fdx # timeout=10*22:02:51* Pruning obsolete
local branches*22:02:51* Fetching upstream changes from
git://gerrit.ovirt.org/vdsm.git*22:02:51*  > git --version #
timeout=10*22:02:51*  > git -c core.askpass=true fetch --tags
--progress git://gerrit.ovirt.org/vdsm.git refs/changes/70/69070/2
--prune*22:02:51* ERROR: Error fetching remote repo 'origin'*22:02:51*
hudson.plugins.git.GitException
:
Failed to fetch from git://gerrit.ovirt.org/vdsm.git*22:02:51*  at
hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
*22:02:51*
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
*22:02:51*
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
*22:02:51*
at 
org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:129)
*22:02:51*
at hudson.scm.SCM.checkout(SCM.java:485)
*22:02:51*
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
*22:02:51*
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
*22:02:51*
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
*22:02:51*
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
*22:02:51*
at hudson.model.Run.execute(Run.java:1738)
*22:02:51*
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
*22:02:51*
at hudson.model.ResourceController.execute(ResourceController.java:98)
*22:02:51*
at hudson.model.Executor.run(Executor.java:410)
*22:02:51*
Caused by: hudson.plugins.git.GitException
:
Command "git -c core.askpass=true fetch --tags --progress
git://gerrit.ovirt.org/vdsm.git refs/changes/70/69070/2 --prune"
returned status code 128:*22:02:51* stdout: *22:02:51* stderr: fatal:
unable to connect to gerrit.ovirt.org:*22:02:51* gerrit.ovirt.org[0:
107.22.212.69]: errno=Connection refused*22:02:51*
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: Failing VDSM CI tests caused by connection refused.

2016-12-25 Thread Maor Lipchuk
seems to work now

Thanks

On Sun, Dec 25, 2016 at 11:45 AM, Eyal Edri  wrote:

> There was a problem with the git daemon on gerrit server which blocked
> git:// access,  which was just solved.
> Can you try to retry and see if its solved?
>
> On Sun, Dec 25, 2016 at 12:07 AM, Maor Lipchuk 
> wrote:
>
>> *Hi,*
>>
>>
>> *I saw also few recent patches failing on the same error, looks like a 
>> network issue:*
>>
>>
>> *22:02:51*  > git clean -fdx # timeout=10*22:02:51* Pruning obsolete local 
>> branches*22:02:51* Fetching upstream changes from 
>> git://gerrit.ovirt.org/vdsm.git*22:02:51*  > git --version # 
>> timeout=10*22:02:51*  > git -c core.askpass=true fetch --tags --progress 
>> git://gerrit.ovirt.org/vdsm.git refs/changes/70/69070/2 --prune*22:02:51* 
>> ERROR: Error fetching remote repo 'origin'*22:02:51* 
>> hudson.plugins.git.GitException 
>> <http://stacktrace.jenkins-ci.org/search?query=hudson.plugins.git.GitException>:
>>  Failed to fetch from git://gerrit.ovirt.org/vdsm.git*22:02:51*at 
>> hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.plugins.git.GitSCM.fetchFrom&entity=method>*22:02:51*
>> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.plugins.git.GitSCM.retrieveChanges&entity=method>*22:02:51*
>>at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.plugins.git.GitSCM.checkout&entity=method>*22:02:51*
>>  at 
>> org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:129) 
>> <http://stacktrace.jenkins-ci.org/search/?query=org.jenkinsci.plugins.multiplescms.MultiSCM.checkout&entity=method>*22:02:51*
>> at hudson.scm.SCM.checkout(SCM.java:485) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.scm.SCM.checkout&entity=method>*22:02:51*
>>at hudson.model.AbstractProject.checkout(AbstractProject.java:1269) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.model.AbstractProject.checkout&entity=method>*22:02:51*
>>   at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
>>  
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout&entity=method>*22:02:51*
>>  at 
>> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) 
>> <http://stacktrace.jenkins-ci.org/search/?query=jenkins.scm.SCMCheckoutStrategy.checkout&entity=method>*22:02:51*
>>   at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
>>  
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.model.AbstractBuild$AbstractBuildExecution.run&entity=method>*22:02:51*
>>  at hudson.model.Run.execute(Run.java:1738) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.model.Run.execute&entity=method>*22:02:51*
>> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.model.FreeStyleBuild.run&entity=method>*22:02:51*
>>  at hudson.model.ResourceController.execute(ResourceController.java:98) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.model.ResourceController.execute&entity=method>*22:02:51*
>>  at hudson.model.Executor.run(Executor.java:410) 
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.model.Executor.run&entity=method>*22:02:51*
>>  Caused by: hudson.plugins.git.GitException 
>> <http://stacktrace.jenkins-ci.org/search?query=hudson.plugins.git.GitException>:
>>  Command "git -c core.askpass=true fetch --tags --progress 
>> git://gerrit.ovirt.org/vdsm.git refs/changes/70/69070/2 --prune" returned 
>> status code 128:*22:02:51* stdout: *22:02:51* stderr: fatal: unable to 
>> connect to gerrit.ovirt.org:*22:02:51* gerrit.ovirt.org[0: 107.22.212.69]: 
>> errno=Connection refused*22:02:51*
>>
>>
>> ___
>> Infra mailing list
>> Infra@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


jenkins dev role for mlipchuk user

2017-03-28 Thread Maor Lipchuk
Hi,

Can you please add dev role to mlipchuk user so I can run the ci manual
tests

Thanks,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: jenkins dev role for mlipchuk user

2017-03-29 Thread Maor Lipchuk
Thanks!
Seems to work

On Wed, Mar 29, 2017 at 12:38 PM, Pavel Zhukov  wrote:

> On Tue, Mar 28 2017, Barak Korren wrote:
>
> > Forwarded to infra-support to open ticket:
> >
> > https://ovirt-jira.atlassian.net/browse/OVIRT-1284
> Done.
> Please verify and let us know if it works or not
> >
> > Barak Korren
> > bkor...@redhat.com
> > RHCE, RHCi, RHV-DevOps Team
> > https://ifireball.wordpress.com/
> >
> > בתאריך 28 במרץ 2017 18:00,‏ "Maor Lipchuk"  כתב:
> >
> > Hi,
> >
> > Can you please add dev role to mlipchuk user so I can run the ci
> manual tests
> >
> > Thanks,
> > Maor
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> > ___
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
>
> --
> Pavel Zhukov
> Software Engineer
>
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


add patche https://gerrit.ovirt.org/#/c/77142/ to jenkins build

2017-06-08 Thread Maor Lipchuk
Hi all,

A user the following message on his gerrit patch:
"http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc25-x86_64/8853/
: To avoid overloading the infrastructure, a whitelist for running
gerrit triggered jobs has been set in place, if you feel like you
should be in it, please contact infra at ovirt dot org."

can you please add all the patche's related jobs to the whitelist:
https://gerrit.ovirt.org/#/c/77142/

Also, can you please update the message at the end :
"please contact infra at ovirt.org"
  instead of:
"please contact infra at ovirt dot org"

Thanks,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Create a new oVirt_DR_site_to_site gerrit repository in gerrit.ovirt.org

2017-07-12 Thread Maor Lipchuk
Hi all,

I would like to create a new repository in our gerrit.ovirt.org which
will include a tool to support DR solution for oVirt (see [1])

Currently it is being developed on my personal github account (see
[2]), but once it will be migrated to be managed in gerrit.ovirt.org
it could be great since I can add it a standard CI tests.

[1] 
https://docs.google.com/document/d/1tMbTVvcS8wKW4c1V_Ee754bFtqRwl2fkPBNDXHpouVE/edit
[2] https://github.com/maorlipchuk/ansible_ovirt_DR

Thanks,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: [ovirt-devel] [rhevm-staff] oVirt website hackathon

2017-09-25 Thread Maor Lipchuk
On Sun, Sep 24, 2017 at 10:38 PM, Tomáš Golembiovský
 wrote:
> On Sun, 24 Sep 2017 17:51:50 +0300
> Eyal Edri  wrote:
>
>> On Sun, Sep 24, 2017 at 4:52 PM, Eyal Edri  wrote:
>>
>> >
>> > On Sun, Sep 24, 2017 at 4:48 PM, Eyal Edri  wrote:
>> >
>> >> Hi,
>> >>
>> >> So I've found linkchecker[1], which is quite a powerful and useful tool
>> >> for that, and run it on oVirt.org, the results are not good, 
>> >> unfortunately.
>> >> We have over 15K(!) of broken links to fix before we can even consider
>> >> adding a constant CI job to check new commits.
>
> How about checking that no *new* broken links are introduced by pull
> requests? Would that be easy enough to do?
>
>
>> >>
>> >> Snippet example from the huge report attached to this email [2]. ( btw
>> >> there are other formats available to generate this report if we want )
>> >>
>> >
>> > resending with zipped report ( the file was 16MB, too big for the list ).
>> >
>>
>> I've rerun the tool excluding .png images, since there are many of them and
>> the broken links got down to 2373, to much more reasonable number
>> to start working on.
>
> 2k is "reasonable"? Really? :)
>
>
>> Attached new report w/o images.
>>
>>
>> >
>> >
>> >>
>> >> After we'll do an initial cleanup of the broken links ( similar to what
>> >> we did on findbugs errors ), we can consider adding CI for it, 2 ideas I
>> >> had in mind:
>> >>
>> >>
>> >> 1. Running the tool on GitHub PR using Travis CI ( which ovirt-site is
>> >> already connected to it ), the tool seems to be using it as well for
>> >> testing itself
>> >> 2. Adding ovirt-site as a std-ci project and using it to also properly
>> >> deploy to the site in the end ( more complex and long term goal, which
>> >> might require more work ).
>> >>
>> >>
>> >> TL;DR, let's schedule a doc-fix day first to address the sheer amount of
>> >> broken links and then worry about adding CI.
>> >>
>> >>
>> >>
>> >> [1] https://github.com/wummel/linkchecker
>> >> [2]
>> >>
>> >> URL `develop/release-management/features/sla/hosted-engine-agent
>> >> -offloading/#documentation'
>> >> Name `Documentation/External references'
>> >> Parent URL https://ovirt.org/develop/release-management/features/sla/
>> >> hosted-engine-agent-offloading/, line 1870, col 131 (HTML
>> >> )
>> >> (CSS
>> >> 
>> >> )
>> >> Real URL https://ovirt.org/develop/release-management/features/sla/
>> >> hosted-engine-agent-offloading/develop/release-management/
>> >> features/sla/hosted-engine-agent-offloading/#documentation
>> >> Size 14.63KB
>> >> Check time 3.496 seconds
>> >> Result Error: 404 Not Found
>> >>
>> >>
>> >> URL `/images/apple-touch-icon-precomposed.png'
>> >> Parent URL https://www.ovirt.org, line 22, col 1 (HTML
>> >> ) (CSS
>> >> 
>> >> )
>> >> Real URL https://www.ovirt.org/images/apple-touch-icon-precomposed.png
>> >> Size 14.63KB
>> >> Check time 1.851 seconds
>> >> Result Error: 404 Not Found
>> >>
>> >>
>> >
>> > --
>> >
>> > Eyal edri
>> >
>> >
>> > ASSOCIATE MANAGER
>> >
>> > RHV DevOps
>> >
>> > EMEA VIRTUALIZATION R&D
>> >
>> >
>> > Red Hat EMEA 
>> >  TRIED. TESTED. TRUSTED. 
>> > phone: +972-9-7692018 <+972%209-769-2018>
>> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
>> >
>>
>>
>>
>> --
>>
>> Eyal edri
>>
>>
>> ASSOCIATE MANAGER
>>
>> RHV DevOps
>>
>> EMEA VIRTUALIZATION R&D
>>
>>
>> Red Hat EMEA 
>>  TRIED. TESTED. TRUSTED. 
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
>
> --
> Tomáš Golembiovský 
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel


Nice!
It reminds me that Daniel and I developed a similar tool last year
(see [1]) which adds the ability of sending an email to the author
which committed the broken link, based on the git repository.
Maybe it can save you some time on fixing all of the broken links and
instead let the committers do it.

[1] https://github.com/chipchaderez/Wiki-Link-Validator

Regards,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


upgrade-from-release-suite-master failure reason

2017-10-17 Thread Maor Lipchuk
Hi all,

I ran several OST on a patchset I'm about to merge.
The standard OST tests finished with success (see [1]), although
upgrade-from-release-suite-master fail for an odd reason of "Failed to
clear zombie commands." (see [2])

I don't recall any changes related to upgrade, so I was wondering if
maybe I'm missing something with my patchset, or it is a known issue
not related to my changes?

[1]
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1384/
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1386/

[2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1385/ :
[ ERROR ] Failed to execute stage 'Setup validation': Failed to clear
zombie commands. Please access support in attempt to resolve the
problem

Regards,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: upgrade-from-release-suite-master failure reason

2017-10-17 Thread Maor Lipchuk
Thanks for the info

On Tue, Oct 17, 2017 at 1:52 PM, Daniel Belenky  wrote:

> Hi Maor,
>
> This patch https://gerrit.ovirt.org/#/c/82615/5 to engine introduced a
> bug in the upgrade process,
> so every patch that is based on top of this one will fail upgrade until a
> fix will be merged.
>
> On Tue, Oct 17, 2017 at 12:55 PM, Maor Lipchuk 
> wrote:
>
>> Hi all,
>>
>> I ran several OST on a patchset I'm about to merge.
>> The standard OST tests finished with success (see [1]), although
>> upgrade-from-release-suite-master fail for an odd reason of "Failed to
>> clear zombie commands." (see [2])
>>
>> I don't recall any changes related to upgrade, so I was wondering if
>> maybe I'm missing something with my patchset, or it is a known issue
>> not related to my changes?
>>
>> [1]
>> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1384/
>> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1386/
>>
>> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1385/ :
>> [ ERROR ] Failed to execute stage 'Setup validation': Failed to clear
>> zombie commands. Please access support in attempt to resolve the
>> problem
>>
>> Regards,
>> Maor
>> ___
>> Infra mailing list
>> Infra@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>
>
>
> --
>
> DANIEL BELENKY
>
> RHV DEVOPS
>
> EMEA VIRTUALIZATION R&D
> <https://red.ht/sig>
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Jenkins OST fails

2017-10-30 Thread Maor Lipchuk
Hi,

I've ran the OST on few patches which I wanted to merge and I got an error
with the following message (see [1]):

[ ERROR ] schema.sh: Please fix numbering to interval 04020701 to
04020710 and run the upgrade script.

[ ERROR ] Failed to execute stage 'Misc configuration': Engine schema
refresh failed\n[ INFO  ] Rolling back database schema


My patch clearly indicates the upgrade script is 04020710 (see [2]).

I wonder if it is somehow related to the reverted patch (see [3])
which removed the upgrade script
packaging/dbscripts/upgrade/04_02_0710_
nullify...



[1] 
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1470/testReport/junit/(root)/001_upgrade_engine/test_initialize_engine/


[2] 
https://gerrit.ovirt.org/#/c/82251/26/packaging/dbscripts/upgrade/04_02_0710_add_entity_status_column_for_unregistered_VM_on_ovf_update.sql


[3] https://gerrit.ovirt.org/#/c/83228/


Regards,

Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: [ovirt-devel] [ OST Failure Report ] [ oVirtMaster ] [ 07-11-2017 ] [007_sd_reattach.deactivate_storage_domain ]

2017-12-07 Thread Maor Lipchuk
CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS is a known issue, the problem is that
we might have tasks which will start running internally using scheduling
(like OVF_UPDATE) and we can't really know how much time every task will
take until it will end.

Even if we check that there are no running tasks it will not guarantee that
no task will start until you deactivate the storage domain.

I think that the best solution for it is an engine support to cancel
running tasks or block tasks from running.

On Thu, Dec 7, 2017 at 12:14 PM, Dafna Ron  wrote:

> Hi,
>
> We had a failure on master basic suite for test 
> 007_sd_reattach.deactivate_storage_domain.
>
>
> The failure was that we failed to deactivate domain due to running tasks.
>
> It does not seem to be related to the patch it was testing and I think
> that the test itself needs to be modified to check there are no running
> tasks.
>
> Is there perhaps a way to query if there are running tasks before running
> the command? can you please take a look at the test on OST?
>
> *Link and headline of suspected patches: Not related to error*
>
> *Link to Job:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/
> *
>
>
> * Link to all logs:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/artifact/
> 
> (Relevant) error snippet from the log:  2017-12-06 20:13:23,166-05
> WARN
> [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand]
> (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Validation of
> action 'DeactivateStorageDomainWithOvfUpdate' fa iled for user
> admin@internal-authz. Reasons:
> VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__DEACTIVATE,ERROR_CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS
> 2017-12-06 20:13:23,167-05 INFO
> [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand]
> (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Lock freed to
> object 'EngineLock:{exclusiveLocks='[ea2fd992-8a
> a4-44fe-aa43-e96754a975ba=STORAGE]',
> sharedLocks='[5e0a0183-0e25-4f43-b5b0-0cfb5510248e=POOL]'}' 2017-12-06
> 20:13:23,172-05 DEBUG
> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
> (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] method: runAction,
> params: [DeactivateStorageDomainWithOvfUpdate, DeactivateSto
> rageDomainWithOvfUpdateParameters:{commandId='630c28e1-41ab-43db-9755-a2bb870dbcb3',
> user='null', commandType='Unknown'}], timeElapsed: 65ms 2017-12-06
> 20:13:23,176-05 ERROR
> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
> task-7) [] Operation Failed: [Cannot deactivate Storage while there are
> running tasks on this Storage. -Please wait until tasks will finish and try
> again.] *
>
>
>
>
>
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: [ovirt-devel] [ OST Failure Report ] [ oVirtMaster ] [ 07-11-2017 ] [007_sd_reattach.deactivate_storage_domain ]

2017-12-10 Thread Maor Lipchuk
On Fri, Dec 8, 2017 at 11:20 PM, Yaniv Kaul  wrote:

>
>
> On Fri, Dec 8, 2017 at 10:39 PM, Yaniv Kaul  wrote:
>
>>
>>
>> On Fri, Dec 8, 2017 at 9:31 PM, Dafna Ron  wrote:
>>
>>> I opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1523813
>>>
>>
>> I'm optimistically hoping https://gerrit.ovirt.org/#/c/85195/ will fix
>> it.
>> Not sure.
>>
>
> Keeps failing with:
> Operation Failed: [Cannot deactivate Storage. The relevant Storage
> Domain's status is Maintenance.]
>
> Which is strange:
> 1. I do check if the SD is in Maint. mode before trying to deactive and
> the test is supposed to be skipped if it is.
>

I've added a comment in the patch,
I suspect it is related to the fact that we fetch the domain from
storage_domains and not attached_storage_domains


> 2. Why can't I deactive a SD when in Maint. mode?
>

I assume that the engine fails since that means that the storage domain is
not connected to the Host and the execute phase of maintenance performs
operations like update ovf store which depend on the storage domain to be
connected.


>
> Probably missing something here.
> Y.
>
> Y.
>>
>>
>>>
>>> Allon, can you please assign someone to help fix this test?
>>> Please let me know if you need help from me.
>>>
>>> Thanks!
>>> Dafna
>>>
>>>
Thanks Dafna, besides the fix which should be done in the OST, here is an
old old bug which might also become useful:
 https://bugzilla.redhat.com/879248
<https://bugzilla.redhat.com/show_bug.cgi?id=879248>


>
>>>
>>> On 12/07/2017 11:59 AM, Yaniv Kaul wrote:
>>>
>>>
>>>
>>> On Thu, Dec 7, 2017 at 1:30 PM, Eyal Shenitzky 
>>> wrote:
>>>
>>>> I think that the maybe the QE can share their methods on how to avoid
>>>> those issues.
>>>> From what I remember, before deactivating storage domain they make sure
>>>> that there are no running tasks related to
>>>> the storage domain.
>>>>
>>>
>>> Looks like an easy fix is to wrap it with try, except sdk4.Error and let
>>> it sit within the testlib.assert_true_within_short() loop.
>>> Y.
>>>
>>>
>>>>
>>>> On Thu, Dec 7, 2017 at 1:22 PM, Yaniv Kaul  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 7, 2017 at 1:12 PM, Dafna Ron  wrote:
>>>>>
>>>>>> Maor, I either need to get new glasses or a magnifier glass to read
>>>>>> what you wrote :-P
>>>>>> when you say running tasks - these are actually running tasks that
>>>>>> may be running because of other tests in ost - correct? wouldn't killing 
>>>>>> or
>>>>>> blocking those can cause other tests to fail?
>>>>>>
>>>>>
>>>>> It might well be the OVF update. How can we, from the API, wait for
>>>>> those tasks to complete? Or should we catch exception and retry?
>>>>> Y.
>>>>>
>>>>>
>>>>>>
>>>>>> On 12/07/2017 11:06 AM, Maor Lipchuk wrote:
>>>>>>
>>>>>> CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS is a known issue, the problem is
>>>>>> that we might have tasks which will start running internally using
>>>>>> scheduling (like OVF_UPDATE) and we can't really know how much time every
>>>>>> task will take until it will end.
>>>>>>
>>>>>> Even if we check that there are no running tasks it will not
>>>>>> guarantee that no task will start until you deactivate the storage
>>>>>> domain.
>>>>>>
>>>>>> I think that the best solution for it is an engine support to cancel
>>>>>> running tasks or block tasks from running.
>>>>>>
>>>>>> On Thu, Dec 7, 2017 at 12:14 PM, Dafna Ron  wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We had a failure on master basic suite for test
>>>>>>> 007_sd_reattach.deactivate_storage_domain.
>>>>>>>
>>>>>>> The failure was that we failed to deactivate domain due to running
>>>>>>> tasks.
>>>>>>>
>>>>>>> It does not seem to be related to the patch it was testing and I

Re: Proposing Liron Aravot as an engine-core maintainer

2015-01-13 Thread Maor Lipchuk
On 01/26/2014 02:47 PM, Tal Nisan wrote:
> Hi core maintainers,
> 
> I would like to propose Liron Aravot as an engine-core maintainer.
> 
> Liron joined the oVirt project on June 2012, and has since contributed
> over 170 patches to master (not counting backports to various stable
> branches).
> 
> He has been instrumental in implementing oVirt's Backup API for external
> providers, and has a been a driving force in improving flows regarding
> SPM election and master domain reconstruction, handling OVF backups and
> various concurrency issues both as a coder and a reviewer.
> 
> Your response would be appreciated.
> 
> Thanks,
> Tal.
> 
> 
+1
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: [Users] [GSOC][Gerrit] add potential reviewers - questions

2015-01-13 Thread Maor Lipchuk
On 03/11/2014 05:20 PM, Itamar Heim wrote:
> On 03/11/2014 05:14 PM, Eyal Edri wrote:
>>
>>
>> - Original Message -
>>> From: "Itamar Heim" 
>>> To: "Eyal Edri" , "Tomasz Kołek"
>>> , us...@ovirt.org, "infra" 
>>> Sent: Tuesday, March 11, 2014 5:10:54 PM
>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions
>>>
>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote:
 On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote:
>> Tomasz Kołek wrote:
>>
>> I've got a few questions about project description.
>> Please tell me if my problem's understanding is good or not.
>> We need to add a few flags/methods to git review module. This flags
>> should
>> allow to add potential reviewers in gerrit.
>> So:
>> Let's assume that we've got special flags for this operations. What's
>> next?
>> 1. In gerrit system we need to add special place for potential
>> reviewers?
>> 2. Potential reviewers should agree that they want to review?
>> 3. We can have more than one accepted reviewer?
>
> I'm not sure i understood exactly what you mean by 'potential
> reviewers'.  do want gerrit (hook?) to automatically add reviewers to
> a patch according to the code sent?  so in fact you'll have a place
> somewhere for mapping code & specific developers?

 I really like this idea. Gerrit currently requires new users to know
 who
 to add as reviewers, IMHO impeding new contributors.

 One relative simple solution would be to look at who recently touched
 the files that are being modified and add them as reviewers. This
 can be
 done by looking at the git log for a file. Some pseudo python code
 solution:

 reviewers = set()

 for modified_file in commit.files:
   reviewers += set(commit.author for commit in
 git.log(modified_file))

 return reviewers

 This gives a system that those who touche a file, become the maintainer
 for that file. A more complex solution could improve on that and limit
 the reviewers added per patch. One can think of limiting to only
 contributions in the last X months, weigh contributions so common
 committers are prefered. It could also combine several methods.

 For example to limit to the 5 authors who touched the most files:

 reviewers = collections.Counter()  # New in python 2.7

 for modified_file in commit.files:
   reviewers += collections.Counter(commit.author for commit in
   git.log(modified_file))

 return [author for author, count in reviewers.most_common(5)]

 Since Counter also accepts a dictionary, one could also weigh the
 touched lines per file. Downside there is big whitespace/formatting
 patches can skew the line count.

 In short, I think an entire thesis could be written on the optimal way
 to determine reviewers but a simple algorithm could do to show the
 method works.

 Does this help?
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users

>>>
>>> I think if we do this, we want to make sure we cover per file who is
>>> required to +2 it before we consider it acked.
>>>
>>
>> won't it require maintaining static lists of people per
>> file/path/project?
>>
> 
> yes, but considering our project layout, i don't see an alternative.
> (some of the layout could be improved to be path based, rather than file
> based)
I think it could be done automatically by analysing the file and see who
mostly changed it recently, since the "owner" of the file might be
dynamic, who ever changed most of it few days ago might be more familiar
with it today

IMO the algorithm of adding the reviewers should be flexible.
For example, using a folder which will contain files, where each file
implement an algorithm to add the reviewers.

for instance we can have two files:
1. Add a reviewers by blame - the contributor which changed recently the
code lines
2. Add a reviewers by file - the contributor who changed most of the
file recently.

Each file will implement the functional operation and will output the
reviewers emails.

The user can then add a new algorithm or change it to be more specific
to its project.
for example the user can add also the maintainers which acked the patch
that was blamed.
> ___
> Users mailing list
> us...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: [Users] [GSOC][Gerrit] add potential reviewers - questions

2015-01-13 Thread Maor Lipchuk
Hi Tomasz,

I'm very please to hear that you are interested in the GSOC project,
see my answers inline.

It's great to see that you know the material pretty well, I'm interested
to hear some more ideas and feedbacks.
I will start a thread soon (Maybe also schedule a call) once getting
more feedbacks from other contributors, so we can brain storm some more
and get practical with it.
If you have any more questions, please don't hesitate to ask me.

thanks,
Maor

On 03/11/2014 04:53 PM, Meital Bourvine wrote:
> Eyal,
> 
> I think that he's asking about [1].
> 
> As far as I understand, the idea is to automatically get the reviewers names, 
> with commands like `git blame`, or from gerrit - get previous reviewers to 
> the same file/module...
> 
> Adding Maor, since he might have some additional info.
> 
> [1] http://www.ovirt.org/Summer_of_Code#Idea:_Gerrit_add_potential_reviewers
> 
> - Original Message -
>> From: "Eyal Edri" 
>> To: "Tomasz Kołek" 
>> Cc: us...@ovirt.org, "infra" 
>> Sent: Tuesday, March 11, 2014 4:37:22 PM
>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions
>>
>>
>>
>> - Original Message -
>>> From: "Tomasz Kołek" 
>>> To: us...@ovirt.org
>>> Sent: Monday, March 10, 2014 9:56:28 PM
>>> Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions
>>>
>>>
>>>
>>> Hi
>>>
>>> I'd like to contribute (within GSOC) in idea: Gerrit add potential
>>> reviewers.
>>>
>>> Maybe at first I’ll introduce myself.
>>> I'm Tomek, student from Poland. I study Computer Science at University of
>>> Wroclaw. The next year will be last year of my first degree study, I hope.
>>> As a python programmer I'm working since one year at Nokia Solutions and
>>> Networks (don't worry I intend to change my job to another or to
>>> participation at GSOC). Every day at work and school I'm using version
>>> control system (Git and SVN). At work we were using to Gerrit as a review
>>> system but currently we're using JIRA to report review statuses.
>>> I love spend my free time in mountains (mainly polish - Tatras mountains).
>>> That's all about me.
>>>
>>> I've got a few questions about project description.
>>> Please tell me if my problem's understanding is good or not.
>>> We need to add a few flags/methods to git review module. This flags should
>>> allow to add potential reviewers in gerrit.
>>> So:
>>> Let's assume that we've got special flags for this operations. What's next?
>>> 1. In gerrit system we need to add special place for potential reviewers?
Adding a plugin to gerrit is an interesting idea although it will
require the administrator to add it in the server, and I want that the
operation will be more available to any submitter in any project.
I think that we can address it in a later phase though.
>>> 2. Potential reviewers should agree that they want to review?
no, since gerrit does not question the reviewer if he wants to be added
or not I think we should keep this behaviour as well.

although as I see it, the operation of adding the reviewers, will not be
completely automatic for the submitter, we should let the submitter of
the patch to choose which reviewers he wants to add, very similar to the
screen being used when doing a rebase in git. (see attached file
add_reviewers.png)
>>> 3. We can have more than one accepted reviewer?
Yes, that is correct.
>>
>> Hi Tomasz,
>> I'm not sure i understood exactly what you mean by 'potential reviewers'.
>> do want gerrit (hook?) to automatically add reviewers to a patch according to
>> the code sent?
>> so in fact you'll have a place somewhere for mapping code & specific
>> developers?
>>
>> cause if you mean by adding reviewers to a patch, that's easily done by just
>> clicking the '+' sign on each patch.
>> those reviewers should have logged in at least once to gerrit.ovirt.org in
>> order to be in the list of potential viewers,
>> and they don't require any special permissions to review with +1/-1 any patch
>> sent.
>> you can add as many reviewers as you want to a patch.
>>
>> does that answer your question?
>>
>> Eyal.
>>
>>
>>
>>>
>>> I know above questions might seem chaotic but I think answers allow me to
>>> better understanding Yours needments
>>>
>>> Best regards
>>> Tomasz Kolek
>>>
>>> ___
>>> Users mailing list
>>> us...@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>> ___
>> Users mailing list
>> us...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: proposing Arik Hadas as a maintainer of engine core

2015-01-13 Thread Maor Lipchuk
On 01/30/2014 10:47 AM, Michal Skrivanek wrote:
> Dear engine-core maintainers,
> I'd like to propose Arik Hadas as a maintainer of oVirt engine backend
> 
> Since he started with oVirt project in October 2012 he was working in various 
> areas in engine core, demonstrated his abilities with more than 200 patches 
> merged to engine master alone. Tons of migration related fixes, refactoring 
> of legacy code, but also new complex features including complementary patches 
> in UI, REST and VDSM code (e.g. Live Snapshots with RAM, locking improvements 
> for VM&Template operations)
> 
> Thanks in advance for your response.
> 
> Thanks,
> michal
> 
+1
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


Re: [Users] [GSOC][Gerrit] add potential reviewers - questions

2015-01-13 Thread Maor Lipchuk
On 03/12/2014 05:57 PM, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "Itamar Heim" 
>> To: "Eli Mesika" , us...@ovirt.org
>> Cc: "Maor Lipchuk" , "Tomasz Kołek" 
>> , "infra" 
>> Sent: Wednesday, March 12, 2014 5:52:25 PM
>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions
>>
>> On 03/12/2014 04:57 PM, Eli Mesika wrote:
>>>
>>>
>>> - Original Message -
>>>> From: "David Caro" 
>>>> To: "Itamar Heim" 
>>>> Cc: "Maor Lipchuk" , us...@ovirt.org, "Tomasz Kołek"
>>>> , "infra"
>>>> 
>>>> Sent: Wednesday, March 12, 2014 11:01:21 AM
>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions
>>>>
>>>> On Wed 12 Mar 2014 08:16:02 AM CET, Itamar Heim wrote:
>>>>> On 03/11/2014 10:08 PM, Maor Lipchuk wrote:
>>>>>> On 03/11/2014 05:20 PM, Itamar Heim wrote:
>>>>>>> On 03/11/2014 05:14 PM, Eyal Edri wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> - Original Message -
>>>>>>>>> From: "Itamar Heim" 
>>>>>>>>> To: "Eyal Edri" , "Tomasz Kołek"
>>>>>>>>> , us...@ovirt.org, "infra" 
>>>>>>>>> Sent: Tuesday, March 11, 2014 5:10:54 PM
>>>>>>>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers -
>>>>>>>>> questions
>>>>>>>>>
>>>>>>>>> On 03/11/2014 05:06 PM, Ewoud Kohl van Wijngaarden wrote:
>>>>>>>>>> On Tue, Mar 11, 2014 at 10:37:22AM -0400, Eyal Edri wrote:
>>>>>>>>>>>> Tomasz Kołek wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I've got a few questions about project description.
>>>>>>>>>>>> Please tell me if my problem's understanding is good or not.
>>>>>>>>>>>> We need to add a few flags/methods to git review module. This
>>>>>>>>>>>> flags
>>>>>>>>>>>> should
>>>>>>>>>>>> allow to add potential reviewers in gerrit.
>>>>>>>>>>>> So:
>>>>>>>>>>>> Let's assume that we've got special flags for this operations.
>>>>>>>>>>>> What's
>>>>>>>>>>>> next?
>>>>>>>>>>>> 1. In gerrit system we need to add special place for potential
>>>>>>>>>>>> reviewers?
>>>>>>>>>>>> 2. Potential reviewers should agree that they want to review?
>>>>>>>>>>>> 3. We can have more than one accepted reviewer?
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure i understood exactly what you mean by 'potential
>>>>>>>>>>> reviewers'.  do want gerrit (hook?) to automatically add reviewers
>>>>>>>>>>> to
>>>>>>>>>>> a patch according to the code sent?  so in fact you'll have a place
>>>>>>>>>>> somewhere for mapping code & specific developers?
>>>>>>>>>>
>>>>>>>>>> I really like this idea. Gerrit currently requires new users to know
>>>>>>>>>> who
>>>>>>>>>> to add as reviewers, IMHO impeding new contributors.
>>>>>>>>>>
>>>>>>>>>> One relative simple solution would be to look at who recently
>>>>>>>>>> touched
>>>>>>>>>> the files that are being modified and add them as reviewers. This
>>>>>>>>>> can be
>>>>>>>>>> done by looking at the git log for a file. Some pseudo python code
>>>>>>>>>> solution:
>>>>>>>>>>
>>>>>>>>>> reviewers = set()
>>>>>>>>>>
>>>>>>>>>> for modified_file in commit.files:
>>>>>>>>>> reviewers += set(commit.a

Re: [Users] [GSOC][Gerrit] add potential reviewers - questions

2015-01-13 Thread Maor Lipchuk
On 03/11/2014 11:17 PM, Tomasz Kołek wrote:
> Hi,
> Thank You for the answers, these  give me basic look at the problem.
> 
> Is not a problem (from my point of view) to implement a few flags for the 
> command, like:
> add reviewers  --auto  --max=5 --using_blame etc, depends only on our 
> requirements.
> 
> I'm almost sure that good way is automatic way as Eyal mentioned, I know it 
> might make a little mess but will be easier for new contributor.
> Why almost? Because what with a situation where all of potential reviewers 
> are not interested to review patch?
> 
> Maybe we should try to find "the most reviewing" people, maybe it will be 
> good way?
That is another method of adding reviewers,
see my suggestion in the thread which I addressed the way we should
implement the algorithms for adding reviewers, so that it will be more
generic.
> 
> 
> BR, 
> Tomek
> 
> -Original Message-
> From: Maor Lipchuk [mailto:mlipc...@redhat.com] 
> Sent: Tuesday, March 11, 2014 8:40 PM
> To: Meital Bourvine; Eyal Edri
> Cc: Tomasz Kołek; us...@ovirt.org; infra
> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - questions
> 
> Hi Tomasz,
> 
> I'm very please to hear that you are interested in the GSOC project, see my 
> answers inline.
> 
> It's great to see that you know the material pretty well, I'm interested to 
> hear some more ideas and feedbacks.
> I will start a thread soon (Maybe also schedule a call) once getting more 
> feedbacks from other contributors, so we can brain storm some more and get 
> practical with it.
> If you have any more questions, please don't hesitate to ask me.
> 
> thanks,
> Maor
> 
> On 03/11/2014 04:53 PM, Meital Bourvine wrote:
>> Eyal,
>>
>> I think that he's asking about [1].
>>
>> As far as I understand, the idea is to automatically get the reviewers 
>> names, with commands like `git blame`, or from gerrit - get previous 
>> reviewers to the same file/module...
>>
>> Adding Maor, since he might have some additional info.
>>
>> [1] 
>> http://www.ovirt.org/Summer_of_Code#Idea:_Gerrit_add_potential_reviewe
>> rs
>>
>> - Original Message -
>>> From: "Eyal Edri" 
>>> To: "Tomasz Kołek" 
>>> Cc: us...@ovirt.org, "infra" 
>>> Sent: Tuesday, March 11, 2014 4:37:22 PM
>>> Subject: Re: [Users] [GSOC][Gerrit] add potential reviewers - 
>>> questions
>>>
>>>
>>>
>>> - Original Message -
>>>> From: "Tomasz Kołek" 
>>>> To: us...@ovirt.org
>>>> Sent: Monday, March 10, 2014 9:56:28 PM
>>>> Subject: [Users] [GSOC][Gerrit] add potential reviewers - questions
>>>>
>>>>
>>>>
>>>> Hi
>>>>
>>>> I'd like to contribute (within GSOC) in idea: Gerrit add potential 
>>>> reviewers.
>>>>
>>>> Maybe at first I’ll introduce myself.
>>>> I'm Tomek, student from Poland. I study Computer Science at 
>>>> University of Wroclaw. The next year will be last year of my first degree 
>>>> study, I hope.
>>>> As a python programmer I'm working since one year at Nokia Solutions 
>>>> and Networks (don't worry I intend to change my job to another or to 
>>>> participation at GSOC). Every day at work and school I'm using 
>>>> version control system (Git and SVN). At work we were using to 
>>>> Gerrit as a review system but currently we're using JIRA to report review 
>>>> statuses.
>>>> I love spend my free time in mountains (mainly polish - Tatras mountains).
>>>> That's all about me.
>>>>
>>>> I've got a few questions about project description.
>>>> Please tell me if my problem's understanding is good or not.
>>>> We need to add a few flags/methods to git review module. This flags 
>>>> should allow to add potential reviewers in gerrit.
>>>> So:
>>>> Let's assume that we've got special flags for this operations. What's next?
>>>> 1. In gerrit system we need to add special place for potential reviewers?
> Adding a plugin to gerrit is an interesting idea although it will require the 
> administrator to add it in the server, and I want that the operation will be 
> more available to any submitter in any project.
> I think that we can address it in a later phase though.
>>>> 2. Potential reviewers should agree that they want to review?
> 

Re: can't send patches to gerrit.ovirt.org

2015-01-13 Thread Maor Lipchuk
now it works

- Original Message -
From: "Maor Lipchuk" 
To: infra@ovirt.org
Sent: Thursday, November 20, 2014 7:52:58 PM
Subject: can't send patches to gerrit.ovirt.org

Hi all,

I'm trying to send a patch to gerrit.ovirt.org but for some reason I'm getting 
connection refused.
I was trying to use ssh and got the same result (see [1]).
My .git/config is described at [2]

Is there a known issue about this?

Thanks for the help,
Maor


[1]
mlipchuk@localhost:~/ovirt-engine(BZ1138115)$ ssh gerrit.ovirt.org
ssh: connect to host gerrit.ovirt.org port 29418: Connection refused

[2]
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = http://gerrit.ovirt.org/ovirt-engine
fetch = +refs/heads/*:refs/remotes/origin/*
[commit]
template = config/engine-commit-template.txt
[branch "ovirt-engine-3.4"]
remote = origin
merge = refs/heads/ovirt-engine-3.4
[branch "ovirt-engine-3.5"]
remote = origin
merge = refs/heads/ovirt-engine-3.5
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


can't send patches to gerrit.ovirt.org

2015-01-13 Thread Maor Lipchuk
Hi all,

I'm trying to send a patch to gerrit.ovirt.org but for some reason I'm getting 
connection refused.
I was trying to use ssh and got the same result (see [1]).
My .git/config is described at [2]

Is there a known issue about this?

Thanks for the help,
Maor


[1]
mlipchuk@localhost:~/ovirt-engine(BZ1138115)$ ssh gerrit.ovirt.org
ssh: connect to host gerrit.ovirt.org port 29418: Connection refused

[2]
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = http://gerrit.ovirt.org/ovirt-engine
fetch = +refs/heads/*:refs/remotes/origin/*
[commit]
template = config/engine-commit-template.txt
[branch "ovirt-engine-3.4"]
remote = origin
merge = refs/heads/ovirt-engine-3.4
[branch "ovirt-engine-3.5"]
remote = origin
merge = refs/heads/ovirt-engine-3.5
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


failing jenkins job

2015-01-13 Thread Maor Lipchuk
Hi,
I'm getting a failing jenkins job at
http://jenkins.ovirt.org/job/vdsm_create_rpms/label=fedora19/954/console.
>From the console it doesn't seem related to the patch change.
Can u please advice me what is the problem?

Thanks,
Maor
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


[JIRA] (OVIRT-2367) Functional tests should support testing disaster recovery scenratios with two ovirt-engine setups to simulate failover and failback

2018-07-24 Thread Maor Lipchuk (oVirt JIRA)
Maor Lipchuk created OVIRT-2367:
---

 Summary: Functional tests should support testing disaster recovery 
scenratios with two ovirt-engine setups to simulate failover and failback
 Key: OVIRT-2367
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2367
 Project: oVirt - virtualization made easy
  Issue Type: Bug
  Components: oVirt CI
Reporter: Maor Lipchuk
Assignee: infra
Priority: High


RHV/oVirt should support functional tests for the disaster recovery feature 
which was introduced in oVirt/RHV 4.2 
The functional tests should support testing disaster recovery scenratios with 
two ovirt-engine setups to simulate failover and failback between the different 
setups.
Here are more resources explaining about the feature and the its usecases:

github project:
https://github.com/oVirt/ovirt-ansible-disaster-recovery/

Documentation:
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/disaster_recovery_guide/#active_passive

Videos demostrating the usecases for oVirt DR:
https://www.youtube.com/watch?v=_TVhU9Sf2uc
https://www.youtube.com/watch?v=uRxsZME6fGs
https://www.youtube.com/watch?v=7dStBp7Wpo0
https://www.youtube.com/watch?v=a44PdFbeIfE
https://youtu.be/ayYrV5IBFUg
https://www.youtube.com/watch?v=rt31-XJ45So&t=8s

[~gbenh...@redhat.com]



--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100090)
___
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/AG5LKATMHRE4GSMUZFF4XJVJUNRZGXZ6/


[JIRA] (OVIRT-2367) Functional tests should support testing disaster recovery scenratios with two ovirt-engine setups to simulate failover and failback

2018-07-24 Thread Maor Lipchuk (oVirt JIRA)

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37602#comment-37602
 ] 

Maor Lipchuk commented on OVIRT-2367:
-

The funtional tests which I want to add is related to the disaster recovery 
scenario, it is not directly related to storage but to the whole setup.
We want to check whether the recovery for the primary setup went well and the 
secondary setup recovered successfully.
For doing that we need the OST to support two engines and after that we can 
start to write functional tests for it
What is the difference between the QE functional tests and the OST functional 
tests.
If you think it is the QE responsibility which ticket should I open for it?

> Functional tests should support testing disaster recovery scenratios with two 
> ovirt-engine setups to simulate failover and failback
> ---
>
> Key: OVIRT-2367
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2367
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: oVirt CI
>Reporter: Maor Lipchuk
>Assignee: infra
>Priority: High
>
> RHV/oVirt should support functional tests for the disaster recovery feature 
> which was introduced in oVirt/RHV 4.2 
> The functional tests should support testing disaster recovery scenratios with 
> two ovirt-engine setups to simulate failover and failback between the 
> different setups.
> Here are more resources explaining about the feature and the its usecases:
> github project:
> https://github.com/oVirt/ovirt-ansible-disaster-recovery/
> Documentation:
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/disaster_recovery_guide/#active_passive
> Videos demostrating the usecases for oVirt DR:
> https://www.youtube.com/watch?v=_TVhU9Sf2uc
> https://www.youtube.com/watch?v=uRxsZME6fGs
> https://www.youtube.com/watch?v=7dStBp7Wpo0
> https://www.youtube.com/watch?v=a44PdFbeIfE
> https://youtu.be/ayYrV5IBFUg
> https://www.youtube.com/watch?v=rt31-XJ45So&t=8s
> [~gbenh...@redhat.com]



--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100090)
___
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/GUTOSR5SPMDID5TON5CK66U5JECMKUZC/


[JIRA] (OVIRT-2367) Functional tests should support testing disaster recovery scenratios with two ovirt-engine setups to simulate failover and failback

2018-07-24 Thread Maor Lipchuk (oVirt JIRA)

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37602#comment-37602
 ] 

Maor Lipchuk edited comment on OVIRT-2367 at 7/24/18 9:42 AM:
--

The funtional tests which I want to add is related to the disaster recovery 
scenario, it is not directly related to storage but to the whole setup.
We want to check whether the recovery for the primary setup went well and the 
secondary setup recovered successfully.
For doing that we need the OST to support two engines and after that we can 
start to write functional tests for it
I'm not sure what is the difference between the QE functional tests and the OST 
functional tests?
If you think it is the QE responsibility which ticket should I open for it?


was (Author: mlipc...@redhat.com):
The funtional tests which I want to add is related to the disaster recovery 
scenario, it is not directly related to storage but to the whole setup.
We want to check whether the recovery for the primary setup went well and the 
secondary setup recovered successfully.
For doing that we need the OST to support two engines and after that we can 
start to write functional tests for it
What is the difference between the QE functional tests and the OST functional 
tests.
If you think it is the QE responsibility which ticket should I open for it?

> Functional tests should support testing disaster recovery scenratios with two 
> ovirt-engine setups to simulate failover and failback
> ---
>
> Key: OVIRT-2367
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2367
> Project: oVirt - virtualization made easy
>  Issue Type: Bug
>  Components: oVirt CI
>Reporter: Maor Lipchuk
>Assignee: infra
>Priority: High
>
> RHV/oVirt should support functional tests for the disaster recovery feature 
> which was introduced in oVirt/RHV 4.2 
> The functional tests should support testing disaster recovery scenratios with 
> two ovirt-engine setups to simulate failover and failback between the 
> different setups.
> Here are more resources explaining about the feature and the its usecases:
> github project:
> https://github.com/oVirt/ovirt-ansible-disaster-recovery/
> Documentation:
> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/disaster_recovery_guide/#active_passive
> Videos demostrating the usecases for oVirt DR:
> https://www.youtube.com/watch?v=_TVhU9Sf2uc
> https://www.youtube.com/watch?v=uRxsZME6fGs
> https://www.youtube.com/watch?v=7dStBp7Wpo0
> https://www.youtube.com/watch?v=a44PdFbeIfE
> https://youtu.be/ayYrV5IBFUg
> https://www.youtube.com/watch?v=rt31-XJ45So&t=8s
> [~gbenh...@redhat.com]



--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100090)
___
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/VBSIGBT2GSS6QS2M75PQAPVQN3PHUA6K/


[JIRA] (OVIRT-1457) Add user to white list for jenkins jobs to run

2017-06-18 Thread Maor Lipchuk (oVirt JIRA)
Maor Lipchuk created OVIRT-1457:
---

 Summary: Add user to white list for jenkins jobs to run
 Key: OVIRT-1457
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1457
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Maor Lipchuk
Assignee: infra


User name: shubham dubey
email: dubey...@gmail.com

Thanks,
Maor



--
This message was sent by Atlassian JIRA
(v1000.1068.0#100050)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


[JIRA] (OVIRT-1528) Create a new oVirt_DR_site_to_site gerrit repository in gerrit.ovirt.org

2017-07-12 Thread Maor Lipchuk (oVirt JIRA)
Maor Lipchuk created OVIRT-1528:
---

 Summary: Create a new oVirt_DR_site_to_site gerrit repository in 
gerrit.ovirt.org
 Key: OVIRT-1528
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1528
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Maor Lipchuk
Assignee: infra


Hi all,

I would like to create a new repository in our gerrit.ovirt.org which
will include a tool to support DR solution for oVirt (see [1])

Currently it is being developed on my personal github account (see
[2]), but once it will be migrated to be managed in gerrit.ovirt.org
it could be great since I can add it a standard CI tests.

[1] 
https://docs.google.com/document/d/1tMbTVvcS8wKW4c1V_Ee754bFtqRwl2fkPBNDXHpouVE/edit
[2] https://github.com/maorlipchuk/ansible_ovirt_DR

Thanks,
Maor



--
This message was sent by Atlassian JIRA
(v1000.1112.0#100055)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


[JIRA] (OVIRT-1528) Create a new oVirt_DR_site_to_site gerrit repository in gerrit.ovirt.org

2017-07-13 Thread Maor Lipchuk (oVirt JIRA)

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33657#comment-33657
 ] 

Maor Lipchuk commented on OVIRT-1528:
-

still relevant

> Create a new oVirt_DR_site_to_site gerrit repository in gerrit.ovirt.org
> 
>
> Key: OVIRT-1528
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1528
> Project: oVirt - virtualization made easy
>  Issue Type: New Feature
>  Components: Gerrit/git
>    Reporter: Maor Lipchuk
>Assignee: Evgheni Dereveanchin
>Priority: Highest
>
> Hi all,
> I would like to create a new repository in our gerrit.ovirt.org which
> will include a tool to support DR solution for oVirt (see [1])
> Currently it is being developed on my personal github account (see
> [2]), but once it will be migrated to be managed in gerrit.ovirt.org
> it could be great since I can add it a standard CI tests.
> [1] 
> https://docs.google.com/document/d/1tMbTVvcS8wKW4c1V_Ee754bFtqRwl2fkPBNDXHpouVE/edit
> [2] https://github.com/maorlipchuk/ansible_ovirt_DR
> Thanks,
> Maor



--
This message was sent by Atlassian JIRA
(v1000.1112.0#100055)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


[JIRA] (OVIRT-1528) Create a new oVirt_DR_site_to_site gerrit repository in gerrit.ovirt.org

2017-07-16 Thread Maor Lipchuk (oVirt JIRA)

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33711#comment-33711
 ] 

Maor Lipchuk commented on OVIRT-1528:
-

Thanks Daniel!

I sent a patch but it seems that I don't have merge rights and +2 on that 
project...
What should I do?

> Create a new oVirt_DR_site_to_site gerrit repository in gerrit.ovirt.org
> 
>
> Key: OVIRT-1528
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1528
> Project: oVirt - virtualization made easy
>  Issue Type: New Feature
>  Components: Gerrit/git
>Reporter: Maor Lipchuk
>Assignee: Daniel Belenky
>Priority: Highest
>
> Hi all,
> I would like to create a new repository in our gerrit.ovirt.org which
> will include a tool to support DR solution for oVirt (see [1])
> Currently it is being developed on my personal github account (see
> [2]), but once it will be migrated to be managed in gerrit.ovirt.org
> it could be great since I can add it a standard CI tests.
> [1] 
> https://docs.google.com/document/d/1tMbTVvcS8wKW4c1V_Ee754bFtqRwl2fkPBNDXHpouVE/edit
> [2] https://github.com/maorlipchuk/ansible_ovirt_DR
> Thanks,
> Maor



--
This message was sent by Atlassian JIRA
(v1000.1119.1#100055)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


[JIRA] (OVIRT-1893) Remove ovirt-ansible-disaster-recovery-1.1 upstream version to install version 0.1 instead

2018-02-12 Thread Maor Lipchuk (oVirt JIRA)
Maor Lipchuk created OVIRT-1893:
---

 Summary: Remove ovirt-ansible-disaster-recovery-1.1 upstream 
version to install version 0.1 instead
 Key: OVIRT-1893
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1893
 Project: oVirt - virtualization made easy
  Issue Type: By-EMAIL
Reporter: Maor Lipchuk
Assignee: infra


Hi all,

It seems that ovirt-ansible-disaster-recovery repo installed from upstream
[1] is installed with version 1.1 [2]:
ovirt-ansible-disaster-recovery-1.1 is broken, because of a bug which was
already fixed [3] in ovirt-ansible-disaster-recovery 0.1.
The thing is that the release which automatically installed is 1.1 although
the fix is available in ovirt-ansible-disaster-recovery 0.1.
Is there a way to do something about it, could we remove the 1.1 versions,
so 0.1 will be installed instead?

[1] http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
[2]
ovirt-ansible-disaster-recovery-1.1.0-0.1.master.20180104150940.el7.centos.noarch
[3] https://github.com/oVirt/ovirt-ansible-disaster-recovery/pull/4

Regards,
Maor



--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100079)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


[JIRA] (OVIRT-1893) Remove ovirt-ansible-disaster-recovery-1.1 upstream version to install version 0.1 instead

2018-02-20 Thread Maor Lipchuk (oVirt JIRA)

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35861#comment-35861
 ] 

Maor Lipchuk commented on OVIRT-1893:
-

We thought about building a newer build
of ovirt-ansible-disaster-recovery-1.1 so it will be installed instead of
the 1.1, but we first need first to solve an issue in the repo.
It could be great if the 1.1 build will be removed since it is currently
broken.

Regards,
Maor


On Tue, Feb 20, 2018 at 4:29 PM, eyal edri (oVirt JIRA) <



> Remove ovirt-ansible-disaster-recovery-1.1 upstream version to install 
> version 0.1 instead
> --
>
> Key: OVIRT-1893
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1893
> Project: oVirt - virtualization made easy
>  Issue Type: By-EMAIL
>Reporter: Maor Lipchuk
>Assignee: infra
>
> Hi all,
> It seems that ovirt-ansible-disaster-recovery repo installed from upstream
> [1] is installed with version 1.1 [2]:
> ovirt-ansible-disaster-recovery-1.1 is broken, because of a bug which was
> already fixed [3] in ovirt-ansible-disaster-recovery 0.1.
> The thing is that the release which automatically installed is 1.1 although
> the fix is available in ovirt-ansible-disaster-recovery 0.1.
> Is there a way to do something about it, could we remove the 1.1 versions,
> so 0.1 will be installed instead?
> [1] http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
> [2]
> ovirt-ansible-disaster-recovery-1.1.0-0.1.master.20180104150940.el7.centos.noarch
> [3] https://github.com/oVirt/ovirt-ansible-disaster-recovery/pull/4
> Regards,
> Maor



--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100080)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra