Re: [ovirt-devel] [VDSM] New network test failure - ctypes.ArgumentError: argument 3: : wrong type

2016-09-20 Thread Nir Soffer 
On Tue, Sep 20, 2016 at 8:18 PM, Nir Soffer  wrote:
> Failed only one patch when building 4, so this looks like
> a random failure, but the error is disturbing.
>
> See 
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/2255/console
>
> 17:00:31 
> ==
> 17:00:31 ERROR: test_bond_create_failure_on_slave_add
> (network.link_bond_test.LinkBondTests)
> 17:00:31 
> --
> 17:00:31 Traceback (most recent call last):
> 17:00:31   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/network/link_bond_test.py",
> line 83, in test_bond_create_failure_on_slave_add
> 17:00:31 base_bond.add_slaves((nic1, nic2))
> 17:00:31   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/bond.py",
> line 153, in add_slaves
> 17:00:31 with _preserve_iface_state(slave):
> 17:00:31   File "/usr/lib64/python3.5/contextlib.py", line 59, in __enter__
> 17:00:31 return next(self.gen)
> 17:00:31   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/bond.py",
> line 214, in _preserve_iface_state
> 17:00:31 dev_was_up = iface.is_up(dev)
> 17:00:31   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/iface.py",
> line 54, in is_up
> 17:00:31 return is_admin_up(dev)
> 17:00:31   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/iface.py",
> line 58, in is_admin_up
> 17:00:31 return is_link_up(get_link(dev)['flags'], 
> check_oper_status=False)
> 17:00:31   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/netlink/link.py",
> line 56, in get_link
> 17:00:31 with _get_link(name=name, sock=sock) as link:
> 17:00:31   File "/usr/lib64/python3.5/contextlib.py", line 59, in __enter__
> 17:00:31 return next(self.gen)
> 17:00:31   File
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/netlink/link.py",
> line 199, in _get_link
> 17:00:31 err = _rtnl_link_get_kernel(sock, index, name, byref(link))
> 17:00:31 ctypes.ArgumentError: argument 3: : wrong type
> 17:00:31  >> begin captured logging << 
> 
> 17:00:31 2016-09-20 17:00:12,586 WARNING [py.warnings] (MainThread)
> /usr/lib/python3.5/site-packages/nose/util.py:453: DeprecationWarning:
> inspect.getargspec() is deprecated, use inspect.signature() instead
> 17:00:31   inspect.getargspec(func)
> 17:00:31  (inspect:1041)
> 17:00:31 2016-09-20 17:00:12,587 INFO  [root] (MainThread) Bond
> check_7lzvb has been created. (bond:142)
> 17:00:31 2016-09-20 17:00:12,598 INFO  [root] (MainThread) Bond
> check_7lzvb has been destroyed. (bond:149)
> 17:00:31 2016-09-20 17:00:12,598 DEBUG [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-15 /sbin/ip link add name dummy_Dmwc5
> type dummy (cwd None) (commands:69)
> 17:00:31 2016-09-20 17:00:12,607 DEBUG [root] (MainThread) SUCCESS:
>  = b'';  = 0 (commands:93)
> 17:00:31 2016-09-20 17:00:12,608 DEBUG [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-15 /sbin/ip link add name dummy_xIK5C
> type dummy (cwd None) (commands:69)
> 17:00:31 2016-09-20 17:00:12,615 DEBUG [root] (MainThread) SUCCESS:
>  = b'';  = 0 (commands:93)
> 17:00:31 2016-09-20 17:00:12,617 INFO  [root] (MainThread) Bond
> bond_rwTTFu has been created. (bond:142)
> 17:00:31 2016-09-20 17:00:12,634 INFO  [root] (MainThread) Bond
> bond_rwTTFu has been destroyed. (bond:149)
> 17:00:31 2016-09-20 17:00:12,634 DEBUG [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-15 /sbin/ip link del dev dummy_Dmwc5
> (cwd None) (commands:69)
> 17:00:31 2016-09-20 17:00:12,658 DEBUG [root] (MainThread) SUCCESS:
>  = b'';  = 0 (commands:93)
> 17:00:31 2016-09-20 17:00:12,659 DEBUG [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-15 /sbin/ip link del dev dummy_xIK5C
> (cwd None) (commands:69)
> 17:00:31 2016-09-20 17:00:12,676 DEBUG [root] (MainThread) SUCCESS:
>  = b'';  = 0 (commands:93)
> 17:00:31 - >> end captured logging << 
> -

Another instance, again only one patch failed when building 5 patches series.

This time with new log format for the tests.

18:56:15 ==
18:56:15 ERROR: test_bond_create_failure_on_slave_add
(network.link_bond_test.LinkBondTests)
18:56:15 --
18:56:15 Traceback (most recent call last):
18:56:15   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/network/link_bond_test.py",
line 83, in test_bond_create_failure_on_slave_add
18:56:15 base_bond.add_slaves((nic1, nic2))
18:56:15   File

[ovirt-devel] [VDSM] Improving vdsm logging format

2016-09-20 Thread Nir Soffer 
Hi all,

We are reviewing patches for improving vdsm log format.

The goal is to have more standard logging format, similar to engine
logs and other logs in the ovirt project, to make it easier to debug
and support the system.

We know that this change will break tools people wrote to parse vdsm
logs (I wrote couple), but we find vdsm log format too painful to work
with, and we hope this is be useful in the long term.

Please review.
https://gerrit.ovirt.org/#/q/topic:log-format

Thanks,
Nir
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [VDSM] New network test failure - ctypes.ArgumentError: argument 3: : wrong type

2016-09-20 Thread Nir Soffer 
Failed only one patch when building 4, so this looks like
a random failure, but the error is disturbing.

See 
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/2255/console

17:00:31 ==
17:00:31 ERROR: test_bond_create_failure_on_slave_add
(network.link_bond_test.LinkBondTests)
17:00:31 --
17:00:31 Traceback (most recent call last):
17:00:31   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/network/link_bond_test.py",
line 83, in test_bond_create_failure_on_slave_add
17:00:31 base_bond.add_slaves((nic1, nic2))
17:00:31   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/bond.py",
line 153, in add_slaves
17:00:31 with _preserve_iface_state(slave):
17:00:31   File "/usr/lib64/python3.5/contextlib.py", line 59, in __enter__
17:00:31 return next(self.gen)
17:00:31   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/bond.py",
line 214, in _preserve_iface_state
17:00:31 dev_was_up = iface.is_up(dev)
17:00:31   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/iface.py",
line 54, in is_up
17:00:31 return is_admin_up(dev)
17:00:31   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/link/iface.py",
line 58, in is_admin_up
17:00:31 return is_link_up(get_link(dev)['flags'], check_oper_status=False)
17:00:31   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/netlink/link.py",
line 56, in get_link
17:00:31 with _get_link(name=name, sock=sock) as link:
17:00:31   File "/usr/lib64/python3.5/contextlib.py", line 59, in __enter__
17:00:31 return next(self.gen)
17:00:31   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/netlink/link.py",
line 199, in _get_link
17:00:31 err = _rtnl_link_get_kernel(sock, index, name, byref(link))
17:00:31 ctypes.ArgumentError: argument 3: : wrong type
17:00:31  >> begin captured logging << 
17:00:31 2016-09-20 17:00:12,586 WARNING [py.warnings] (MainThread)
/usr/lib/python3.5/site-packages/nose/util.py:453: DeprecationWarning:
inspect.getargspec() is deprecated, use inspect.signature() instead
17:00:31   inspect.getargspec(func)
17:00:31  (inspect:1041)
17:00:31 2016-09-20 17:00:12,587 INFO  [root] (MainThread) Bond
check_7lzvb has been created. (bond:142)
17:00:31 2016-09-20 17:00:12,598 INFO  [root] (MainThread) Bond
check_7lzvb has been destroyed. (bond:149)
17:00:31 2016-09-20 17:00:12,598 DEBUG [root] (MainThread)
/usr/bin/taskset --cpu-list 0-15 /sbin/ip link add name dummy_Dmwc5
type dummy (cwd None) (commands:69)
17:00:31 2016-09-20 17:00:12,607 DEBUG [root] (MainThread) SUCCESS:
 = b'';  = 0 (commands:93)
17:00:31 2016-09-20 17:00:12,608 DEBUG [root] (MainThread)
/usr/bin/taskset --cpu-list 0-15 /sbin/ip link add name dummy_xIK5C
type dummy (cwd None) (commands:69)
17:00:31 2016-09-20 17:00:12,615 DEBUG [root] (MainThread) SUCCESS:
 = b'';  = 0 (commands:93)
17:00:31 2016-09-20 17:00:12,617 INFO  [root] (MainThread) Bond
bond_rwTTFu has been created. (bond:142)
17:00:31 2016-09-20 17:00:12,634 INFO  [root] (MainThread) Bond
bond_rwTTFu has been destroyed. (bond:149)
17:00:31 2016-09-20 17:00:12,634 DEBUG [root] (MainThread)
/usr/bin/taskset --cpu-list 0-15 /sbin/ip link del dev dummy_Dmwc5
(cwd None) (commands:69)
17:00:31 2016-09-20 17:00:12,658 DEBUG [root] (MainThread) SUCCESS:
 = b'';  = 0 (commands:93)
17:00:31 2016-09-20 17:00:12,659 DEBUG [root] (MainThread)
/usr/bin/taskset --cpu-list 0-15 /sbin/ip link del dev dummy_xIK5C
(cwd None) (commands:69)
17:00:31 2016-09-20 17:00:12,676 DEBUG [root] (MainThread) SUCCESS:
 = b'';  = 0 (commands:93)
17:00:31 - >> end captured logging << -
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

2016-09-20 Thread Nir Soffer 
On Tue, Sep 20, 2016 at 11:27 AM, Eyal Edri  wrote:

>
>
> On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri  wrote:
>>
>>>
>>>
>>> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola 
>>> wrote:
>>>


 On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  wrote:

> Hi,
>
> Following [1] I'd like to propose to remove rpm building from the
> 'check-merged.sh' script from ovirt-engine (master for now).
>
> The job [2] takes on avg 15 min while actually the rpms are built
> already in check-patch
> (with gwt draft mode if needed) and runs exactly the same build rpm
> command as check-patch [3].
>
> So there isn't real value in running exactly the same rpm build post
> merge, and we already build full permutation mode in 'build-artifacts.sh'.
>
> Any reason to keep it?
> We can cut down valuable time in CI if we drop it and vacant more time
> for more meaningful tests.
>


 This depends on the flow: if we make check_merge gating to the merge
 and to the build we should keep the rpm build becuase at merge a rebase is
 done automatically.

>>>
>>> What do you mean by 'gating to the merge'? I'm not sure I understand
>>> what it means.
>>> Isn't check-patch.sh does the gating? check-merge runs post merge so its
>>> already too late to gate the code ...
>>> And I think check-merge and check-patch currently runs the same rpmbuild
>>> command, so I don't see how check-merged has any value over check-patch.
>>>
>>
>> when merge command is issued a rebase is done as well. We still need a
>> check-merged job because the code checked by check-patch is not the same
>> anymore when check-merged runs.
>>
>
> OK, now I understand, so indeed check-merge can potentially run on
> different code than check-patch and possibly fail due to it.
>

If we require only fast-forward merges, there is no way to merge patch
before a rebase. Once you rebase a patch, check-patch runs...

So check-merge may be unneeded in this case.


>
>
>> In original desing of stdci, check-merged was supposed to become a gating
>> test for build-artifacts.
>>
>
> We have it in our backlog, i.e installing Zuul and adding gating for the
> check-merged jobs, its mostly relevant for system jobs, but we can
> defiently do it first for simple 'check-merged.sh' jobs
> as part of standard CI.
>
> Opened a ticket for it [1]
>
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-734
>
>>
>>
>>
>>
>>>
>>>
 If there's not gating process performed by check-merge then I agree in
 dropping rpm build.



>
>
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> [2] http://jenkins.ovirt.org/job/ovirt-engine_master_check-m
> erged-el7-x86_64/buildTimeTrend
> [3]
> rpmbuild \
> -D "_rpmdir $PWD/output" \
> -D "_topmdir $PWD/rpmbuild" \
> -D "release_suffix ${SUFFIX}" \
> -D "ovirt_build_ut $BUILD_UT" \
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> -D "ovirt_build_draft 1" \
> --rebuild output/*.src.rpm
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>



 --
 Sandro Bonazzola
 Better technology. Faster innovation. Powered by community
 collaboration.
 See how it works at redhat.com
 

>>>
>>>
>>>
>>> --
>>> Eyal Edri
>>> Associate Manager
>>> RHV DevOps
>>> EMEA ENG Virtualization R
>>> Red Hat Israel
>>>
>>> phone: +972-9-7692018
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> 
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Best (and up-to-date) practices for developers?

2016-09-20 Thread Phillip Bailey 
I like that idea. I would prefer having the smaller, more focused files in
a directory. I would probably call it documentation or something similar,
though.

-Phillip Bailey

On Tue, Sep 20, 2016 at 9:14 AM, Roy Golan  wrote:

>
>
> On 19 September 2016 at 15:18, Martin Betak  wrote:
>
>> Yeah definitely +1.
>>
>> Even after being with the project for some time, I often wonder about
>> things
>> like in what order should fields in class be based on their function (as
>> in
>> logger, static sonstants, @Injected dependencies, actual instance
>> fields...)
>> so such document could answer questions like this (that are not encoded in
>> existing checkstyle rules) or provide general high-level guidance
>> throughout
>> the code base - at least for things that don't change that much. For
>> example
>> I believe that the process to invoke a command (or a query) from the
>> Backend
>> via the VdcActionType, CommandFactory .etc hasn't changed that much,
>> and probably won't change in the foreseeable future :-)
>>
>> Martin B.
>>
>> - Original Message -
>> > From: "Phillip Bailey" 
>> > To: "Martin Sivak" 
>> > Cc: "engine-de...@ovirt.org" 
>> > Sent: Monday, September 19, 2016 1:54:23 PM
>> > Subject: Re: [ovirt-devel] Best (and up-to-date) practices for
>> developers?
>> >
>> > +1 for the idea if it doesn't already exist. It would ease development
>> for
>> > those already working on the project, but it would also make it easier
>> for
>> > others who would like to contribute to it, but aren't comfortable with
>> > navigating such a large code base.
>> >
>> > -Phillip Bailey
>> >
>> > On Mon, Sep 19, 2016 at 3:56 AM, Martin Sivak < msi...@redhat.com >
>> wrote:
>> >
>> >
>> > Hi,
>> >
>> > I just wanted to find out if we have some documentation for the
>> > developers that would give hint on different aspects of the engine
>> > development in terms of coding.
>> >
>> > Like:
>> > - code style (we have the config in sources)
>> > - what libraries are (not) allowed (guava..ehm..)
>> > - how should CDI be used (see https://gerrit.ovirt.org/#/c/63747/ )
>> > - what files need to be touched to properly support translations
>> > - ...
>> >
>> >
>> > It would be cool to have something brief we can search easily. I know
>> > it can get outdated fast, but if we use it only for the important
>> > stuff and review it for each major release (as the major rules do not
>> > change much) we should be able to keep it usable.
>> >
>> > --
>> > Martin Sivák
>> > SLA / oVirt
>> > ___
>> > 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
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> I'm all for creating a series of files under our repo for that (and not
> under ovirt-site)
> Something like:
>
> ovirt-engine/
>  - ENGINE_OVERVIEW.adoc
>  - INTERNAL_APIS.adoc
>  - BEST_PRACTICES.adoc
>  - CODING_GUIDES.adoc
>  - REVIEW_GUIDES.adoc
>
> - Another option is to create a long DEVELOPER.adoc (harder to maintain)
> - Or put all those under ovirt-engine/developer/
>
> * I remember there was an initiative for code-of-conduct. Is it alive?
>
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Best (and up-to-date) practices for developers?

2016-09-20 Thread Roy Golan 
On 19 September 2016 at 15:18, Martin Betak  wrote:

> Yeah definitely +1.
>
> Even after being with the project for some time, I often wonder about
> things
> like in what order should fields in class be based on their function (as in
> logger, static sonstants, @Injected dependencies, actual instance
> fields...)
> so such document could answer questions like this (that are not encoded in
> existing checkstyle rules) or provide general high-level guidance
> throughout
> the code base - at least for things that don't change that much. For
> example
> I believe that the process to invoke a command (or a query) from the
> Backend
> via the VdcActionType, CommandFactory .etc hasn't changed that much,
> and probably won't change in the foreseeable future :-)
>
> Martin B.
>
> - Original Message -
> > From: "Phillip Bailey" 
> > To: "Martin Sivak" 
> > Cc: "engine-de...@ovirt.org" 
> > Sent: Monday, September 19, 2016 1:54:23 PM
> > Subject: Re: [ovirt-devel] Best (and up-to-date) practices for
> developers?
> >
> > +1 for the idea if it doesn't already exist. It would ease development
> for
> > those already working on the project, but it would also make it easier
> for
> > others who would like to contribute to it, but aren't comfortable with
> > navigating such a large code base.
> >
> > -Phillip Bailey
> >
> > On Mon, Sep 19, 2016 at 3:56 AM, Martin Sivak < msi...@redhat.com >
> wrote:
> >
> >
> > Hi,
> >
> > I just wanted to find out if we have some documentation for the
> > developers that would give hint on different aspects of the engine
> > development in terms of coding.
> >
> > Like:
> > - code style (we have the config in sources)
> > - what libraries are (not) allowed (guava..ehm..)
> > - how should CDI be used (see https://gerrit.ovirt.org/#/c/63747/ )
> > - what files need to be touched to properly support translations
> > - ...
> >
> >
> > It would be cool to have something brief we can search easily. I know
> > it can get outdated fast, but if we use it only for the important
> > stuff and review it for each major release (as the major rules do not
> > change much) we should be able to keep it usable.
> >
> > --
> > Martin Sivák
> > SLA / oVirt
> > ___
> > 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
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>


I'm all for creating a series of files under our repo for that (and not
under ovirt-site)
Something like:

ovirt-engine/
 - ENGINE_OVERVIEW.adoc
 - INTERNAL_APIS.adoc
 - BEST_PRACTICES.adoc
 - CODING_GUIDES.adoc
 - REVIEW_GUIDES.adoc

- Another option is to create a long DEVELOPER.adoc (harder to maintain)
- Or put all those under ovirt-engine/developer/

* I remember there was an initiative for code-of-conduct. Is it alive?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Updating permissions on gerrit.ovirt.org

2016-09-20 Thread Shlomo Ben David 
Hi All,

On the upcoming days i'm going to update permissions on gerrit.ovirt.org
server.
The changes shouldn't reflect on the current state but if you'll encounter
with any permission issues or other issues related to gerrit.ovirt.org
server please let me or in...@ovirt.org to know and we'll handle it ASAP.

Best Regards,

Shlomi Ben-David | DevOps Engineer | Red Hat ISRAEL
RHCSA | RHCE
IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)

OPEN SOURCE - 1 4 011 && 011 4 1
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

2016-09-20 Thread Eyal Edri 
On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola 
wrote:

>
>
> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri  wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  wrote:
>>>
 Hi,

 Following [1] I'd like to propose to remove rpm building from the
 'check-merged.sh' script from ovirt-engine (master for now).

 The job [2] takes on avg 15 min while actually the rpms are built
 already in check-patch
 (with gwt draft mode if needed) and runs exactly the same build rpm
 command as check-patch [3].

 So there isn't real value in running exactly the same rpm build post
 merge, and we already build full permutation mode in 'build-artifacts.sh'.

 Any reason to keep it?
 We can cut down valuable time in CI if we drop it and vacant more time
 for more meaningful tests.

>>>
>>>
>>> This depends on the flow: if we make check_merge gating to the merge and
>>> to the build we should keep the rpm build becuase at merge a rebase is done
>>> automatically.
>>>
>>
>> What do you mean by 'gating to the merge'? I'm not sure I understand what
>> it means.
>> Isn't check-patch.sh does the gating? check-merge runs post merge so its
>> already too late to gate the code ...
>> And I think check-merge and check-patch currently runs the same rpmbuild
>> command, so I don't see how check-merged has any value over check-patch.
>>
>
> when merge command is issued a rebase is done as well. We still need a
> check-merged job because the code checked by check-patch is not the same
> anymore when check-merged runs.
>

OK, now I understand, so indeed check-merge can potentially run on
different code than check-patch and possibly fail due to it.


> In original desing of stdci, check-merged was supposed to become a gating
> test for build-artifacts.
>

We have it in our backlog, i.e installing Zuul and adding gating for the
check-merged jobs, its mostly relevant for system jobs, but we can
defiently do it first for simple 'check-merged.sh' jobs
as part of standard CI.

Opened a ticket for it [1]

[1] https://ovirt-jira.atlassian.net/browse/OVIRT-734

>
>
>
>
>>
>>
>>> If there's not gating process performed by check-merge then I agree in
>>> dropping rpm build.
>>>
>>>
>>>


 [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
 [2] http://jenkins.ovirt.org/job/ovirt-engine_master_check-m
 erged-el7-x86_64/buildTimeTrend
 [3]
 rpmbuild \
 -D "_rpmdir $PWD/output" \
 -D "_topmdir $PWD/rpmbuild" \
 -D "release_suffix ${SUFFIX}" \
 -D "ovirt_build_ut $BUILD_UT" \
 -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
 -D "ovirt_build_draft 1" \
 --rebuild output/*.src.rpm


 --
 Eyal Edri
 Associate Manager
 RHV DevOps
 EMEA ENG Virtualization R
 Red Hat Israel

 phone: +972-9-7692018
 irc: eedri (on #tlv #rhev-dev #rhev-integ)

>>>
>>>
>>>
>>> --
>>> Sandro Bonazzola
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at redhat.com
>>> 
>>>
>>
>>
>>
>> --
>> Eyal Edri
>> Associate Manager
>> RHV DevOps
>> EMEA ENG Virtualization R
>> Red Hat Israel
>>
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
>



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

2016-09-20 Thread Nir Soffer 
On Tue, Sep 20, 2016 at 9:45 AM, Tal Nisan  wrote:
> +1 from me as well

+1
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] test-repo_ovirt_experimental_master job - failed

2016-09-20 Thread Sandro Bonazzola 
On Fri, Sep 9, 2016 at 1:19 PM, Yaniv Kaul  wrote:

> Indeed, this is the log collector. I wonder if we collect its logs...
> Y.
>

This can't be log-collector, it can be sos vdsm plugin.
That said, if we run log-collector within lago we should collect the
results as job artifacts.



>
>
> On Thu, Sep 8, 2016 at 6:54 PM, Eyal Edri  wrote:
>
>> I'm pretty sure lago or ovirt system tests aren't doing it but its the
>> log collector which is running during that test, I'm not near a computer so
>> can't verify it yet.
>>
>> On Sep 8, 2016 6:05 PM, "Nir Soffer"  wrote:
>>
>>> On Thu, Sep 8, 2016 at 5:45 PM, Eyal Edri  wrote:
>>> > Adding devel.
>>> >
>>> > On Thu, Sep 8, 2016 at 5:43 PM, Shlomo Ben David 
>>> > wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Job [1] is failing with the following error:
>>> >>
>>> >> lago.ssh: DEBUG: Command 8de75538 on lago_basic_suite_master_engine
>>> >> errors:
>>> >>  ERROR: Failed to collect logs from: 192.168.200.2; /bin/ls:
>>> >> /rhev/data-center/mnt/blockSD/eb8c9f48-5f23-48dc-ab7d-945189
>>> 0fd422/master/tasks/1350bed7-443e-4ae6-ae1f-9b24d18c70a8.temp:
>>> >> No such file or directory
>>> >> /bin/ls: cannot open directory
>>> >> /rhev/data-center/mnt/blockSD/eb8c9f48-5f23-48dc-ab7d-945189
>>> 0fd422/master/tasks/1350bed7-443e-4ae6-ae1f-9b24d18c70a8.temp:
>>> >> No such file or directory
>>>
>>> This looks like a lago issue - it should never read anything inside /rhev
>>>
>>> This is a private directory for vdsm, no other process should ever depend
>>> on the content inside this directory, or even on the fact that it exists.
>>>
>>> In particular, /rhev/data-center/mnt/blockSD/*/master/tasks/*.temp
>>> Is not a log file, and lago should not collect it.
>>>
>>> Nir
>>>
>>> >> lago.utils: ERROR: Error while running thread
>>> >> Traceback (most recent call last):
>>> >>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 53, in
>>> >> _ret_via_queue
>>> >> queue.put({'return': func()})
>>> >>   File
>>> >> "/home/jenkins/workspace/test-repo_ovirt_experimental_master
>>> /ovirt-system-tests/basic_suite_master/test-scenarios/002_bootstrap.py",
>>> >> line 493, in log_collector
>>> >> result.code, 0, 'log collector failed. Exit code is %s' %
>>> result.code
>>> >>   File "/usr/lib/python2.7/site-packages/nose/tools/trivial.py",
>>> line 29,
>>> >> in eq_
>>> >> raise AssertionError(msg or "%r != %r" % (a, b))
>>> >> AssertionError: log collector failed. Exit code is 2
>>> >>
>>> >>
>>> >> * The previous issue already fixed (SDK) and now we have a new issue
>>> on
>>> >> the same area.
>>> >>
>>> >>
>>> >> [1] -
>>> >> http://jenkins.ovirt.org/view/experimental%20jobs/job/test-r
>>> epo_ovirt_experimental_master/1462/testReport/(root)/002_boo
>>> tstrap/add_secondary_storage_domains/
>>> >>
>>> >>
>>> >> Best Regards,
>>> >>
>>> >> Shlomi Ben-David | DevOps Engineer | Red Hat ISRAEL
>>> >> RHCSA | RHCE
>>> >> IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)
>>> >>
>>> >> OPEN SOURCE - 1 4 011 && 011 4 1
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Eyal Edri
>>> > Associate Manager
>>> > RHV DevOps
>>> > EMEA ENG Virtualization R
>>> > Red Hat Israel
>>> >
>>> > phone: +972-9-7692018
>>> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>> >
>>> > ___
>>> > Devel mailing list
>>> > Devel@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Proposing Martin Sivak as a Backend Maintainer for SLA & Scheduling

2016-09-20 Thread Tal Nisan 
+1 from me as well

On Mon, Sep 19, 2016 at 6:41 PM, Martin Perina  wrote:

>
>
> On Mon, Sep 19, 2016 at 2:12 PM, Doron Fediuck 
> wrote:
>
>> Hi All,
>>
>> Martin Sivak has been working on the oVirt engine since June 2013.
>> His main focus over the years was around MoM, external scheduler, 
>> hosted-engine, and
>> related engine code.
>>
>> In the past year Martin took over many of the oVirt scheduler related work 
>> and did a lot of improvements there. In total Martin has around 170 engine 
>> patches already merged.
>>
>> Within these you will find improving the scheduler's notifications and error 
>> handling, rewriting the pending resource mechanism which resolved many 
>> issues, VM affinity, affinity labels and multiple improvements for our 
>> scheduling policies and hosted engine.
>>
>> I would like to thank Martin for his great contribution and hope for many 
>> more patches to come :)
>>
>> I would also like to propose Martin as an engine maintainer for SLA and 
>> Scheduling.
>>
>>
> ​+1, well deserved!
> ​
>
>
>> Thanks, Doron
>>
>>
>>
>> ___
>> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

2016-09-20 Thread Sandro Bonazzola 
On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri  wrote:

>
>
> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  wrote:
>>
>>> Hi,
>>>
>>> Following [1] I'd like to propose to remove rpm building from the
>>> 'check-merged.sh' script from ovirt-engine (master for now).
>>>
>>> The job [2] takes on avg 15 min while actually the rpms are built
>>> already in check-patch
>>> (with gwt draft mode if needed) and runs exactly the same build rpm
>>> command as check-patch [3].
>>>
>>> So there isn't real value in running exactly the same rpm build post
>>> merge, and we already build full permutation mode in 'build-artifacts.sh'.
>>>
>>> Any reason to keep it?
>>> We can cut down valuable time in CI if we drop it and vacant more time
>>> for more meaningful tests.
>>>
>>
>>
>> This depends on the flow: if we make check_merge gating to the merge and
>> to the build we should keep the rpm build becuase at merge a rebase is done
>> automatically.
>>
>
> What do you mean by 'gating to the merge'? I'm not sure I understand what
> it means.
> Isn't check-patch.sh does the gating? check-merge runs post merge so its
> already too late to gate the code ...
> And I think check-merge and check-patch currently runs the same rpmbuild
> command, so I don't see how check-merged has any value over check-patch.
>

when merge command is issued a rebase is done as well. We still need a
check-merged job because the code checked by check-patch is not the same
anymore when check-merged runs.
In original desing of stdci, check-merged was supposed to become a gating
test for build-artifacts.




>
>
>> If there's not gating process performed by check-merge then I agree in
>> dropping rpm build.
>>
>>
>>
>>>
>>>
>>> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
>>> [2] http://jenkins.ovirt.org/job/ovirt-engine_master_check-m
>>> erged-el7-x86_64/buildTimeTrend
>>> [3]
>>> rpmbuild \
>>> -D "_rpmdir $PWD/output" \
>>> -D "_topmdir $PWD/rpmbuild" \
>>> -D "release_suffix ${SUFFIX}" \
>>> -D "ovirt_build_ut $BUILD_UT" \
>>> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
>>> -D "ovirt_build_draft 1" \
>>> --rebuild output/*.src.rpm
>>>
>>>
>>> --
>>> Eyal Edri
>>> Associate Manager
>>> RHV DevOps
>>> EMEA ENG Virtualization R
>>> Red Hat Israel
>>>
>>> phone: +972-9-7692018
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> 
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>



-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel