Re: [ovirt-devel] [kubevirt-dev] Re: [virt-tools-list] Project for profiles and defaults for libvirt domains

[Yaniv Lavi]

[resending to include KubeVirt devs ]

YANIV LAVI

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ylavi
  TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat



On Wed, Apr 4, 2018 at 7:07 PM, Yaniv Lavi  wrote:

> Hi,
> I'd like to go one step back and discuss why we should try to do this on
> the high level.
>
> For the last 5-10 years of KVM development, we are pragmatically providing
> the Linux host level APIs via project specific host agents/integration code
> (Nova agent, oVirt host agent, virt-manager).
> In recent time we see new projects that have similar requirements
> (Cockpit, different automation tool, KubeVirt), this means that all of the
> Linux virt stack consumers are reinventing the wheel and using very
> different paths to consume the partial solutions that are provided today.
>
> The use of the Linux virt stack is well defined by the existing projects
> scope and it makes a lot of sense to try to provide the common patterns via
> the virt stack directly as a host level API that different client or
> management consume.
> The main goal is to improve the developer experience for virtualization
> management applications with an API set that is useful to the entire set of
> tools (OSP, oVirt, KubeVirt, Cockpit and so on).
>
> The Linux virt developer community currently is not able to provide best
> practices and optimizations from single node knowledge. This means that all
> of that smarts is locked to the specific project integration in the good
> case or not provided at all and the projects as a whole lose from that.
> When testing the Linux virt stack itself and since each project has
> different usage pattern, we lose the ability to test abilities on the lower
> level making the entire stack less stable and complete for new features.
>
> This also limits the different projects ability to contribute back to the
> Linux stack based on their user and market experience for others in open
> source to gain.
>
> I understand this shift is technically challenging for existing projects,
> but I do see value in doing this even for new implementation like Cockpit
> and KubeVirt.
> I also believe that the end result could be appealing enough to cause
> project like OSP, virt-manager and oVirt to consider to reduce the existing
> capabilities of their host side integrations/agents to shims on the host
> level and reuse the common/better-tested pattern as clients that was
> developed against the experience of the different projects.
>
> I call us all to collaborate and try to converge on a solution that will
> help all in the long term in the value you get from the common base.
>
>
> Thanks,
>
> YANIV LAVI
>
> SENIOR TECHNICAL PRODUCT MANAGER
>
> Red Hat Israel Ltd. 
>
> 34 Jerusalem Road, Building A, 1st floor
>
> Ra'anana, Israel 4350109
>
> yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: 
> ylavi
>   TRIED. TESTED. TRUSTED. 
> @redhatnews    Red Hat 
>    Red Hat 
> 
>
>
> On Thu, Mar 22, 2018 at 7:18 PM, Daniel P. Berrangé 
> wrote:
>
>> On Thu, Mar 22, 2018 at 03:54:01PM +0100, Martin Kletzander wrote:
>> > >
>> > > > One more thing could be automatically figuring out best values
>> based on
>> > > > libosinfo-provided data.
>> > > >
>> > > > 2) Policies
>> > > >
>> > > > Lot of the time there are parts of the domain definition that need
>> to be
>> > > > added, but nobody really cares about them.  Sometimes it's enough to
>> > > > have few templates, another time you might want to have a policy
>> > > > per-scenario and want to combine them in various ways.  For example
>> with
>> > > > the data provided by point 1).
>> > > >
>> > > > For example if you want PCI-Express, you need the q35 machine type,
>> but
>> > > > you don't really want to care about the machine type.  Or you want
>> to
>> > > > use SPICE, but you don't want to care about adding QXL.
>> > > >
>> > > > What if some of these policies could be specified once (using some
>> DSL
>> > > > for example), and used by virtuned to merge them in a unified and
>> > > > predictable way?
>> > > >
>> > > > 3) Abstracting the XML
>> > > >
>> > > > This is probably just usable for stateless apps, but it might happen
>> > > > that some apps don't really want to care about the XML at all.  They
>> > > > just want an abstract view of the domain, possibly add/remove a
>> device
>> > > > and that's it.  We could do that as well.  I can't really tell how
>> much
>> > > > of a demand there is for it, though

Re: [ovirt-devel] [kubevirt-dev] Re: [virt-tools-list] Project for profiles and defaults for libvirt domains

[Yaniv Lavi]

Hi,
I'd like to go one step back and discuss why we should try to do this on
the high level.

For the last 5-10 years of KVM development, we are pragmatically providing
the Linux host level APIs via project specific host agents/integration code
(Nova agent, oVirt host agent, virt-manager).
In recent time we see new projects that have similar requirements (Cockpit,
different automation tool, KubeVirt), this means that all of the Linux virt
stack consumers are reinventing the wheel and using very different paths to
consume the partial solutions that are provided today.

The use of the Linux virt stack is well defined by the existing projects
scope and it makes a lot of sense to try to provide the common patterns via
the virt stack directly as a host level API that different client or
management consume.
The main goal is to improve the developer experience for virtualization
management applications with an API set that is useful to the entire set of
tools (OSP, oVirt, KubeVirt, Cockpit and so on).

The Linux virt developer community currently is not able to provide best
practices and optimizations from single node knowledge. This means that all
of that smarts is locked to the specific project integration in the good
case or not provided at all and the projects as a whole lose from that.
When testing the Linux virt stack itself and since each project has
different usage pattern, we lose the ability to test abilities on the lower
level making the entire stack less stable and complete for new features.

This also limits the different projects ability to contribute back to the
Linux stack based on their user and market experience for others in open
source to gain.

I understand this shift is technically challenging for existing projects,
but I do see value in doing this even for new implementation like Cockpit
and KubeVirt.
I also believe that the end result could be appealing enough to cause
project like OSP, virt-manager and oVirt to consider to reduce the existing
capabilities of their host side integrations/agents to shims on the host
level and reuse the common/better-tested pattern as clients that was
developed against the experience of the different projects.

I call us all to collaborate and try to converge on a solution that will
help all in the long term in the value you get from the common base.


Thanks,

YANIV LAVI

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ylavi
  TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat



On Thu, Mar 22, 2018 at 7:18 PM, Daniel P. Berrangé 
wrote:

> On Thu, Mar 22, 2018 at 03:54:01PM +0100, Martin Kletzander wrote:
> > >
> > > > One more thing could be automatically figuring out best values based
> on
> > > > libosinfo-provided data.
> > > >
> > > > 2) Policies
> > > >
> > > > Lot of the time there are parts of the domain definition that need
> to be
> > > > added, but nobody really cares about them.  Sometimes it's enough to
> > > > have few templates, another time you might want to have a policy
> > > > per-scenario and want to combine them in various ways.  For example
> with
> > > > the data provided by point 1).
> > > >
> > > > For example if you want PCI-Express, you need the q35 machine type,
> but
> > > > you don't really want to care about the machine type.  Or you want to
> > > > use SPICE, but you don't want to care about adding QXL.
> > > >
> > > > What if some of these policies could be specified once (using some
> DSL
> > > > for example), and used by virtuned to merge them in a unified and
> > > > predictable way?
> > > >
> > > > 3) Abstracting the XML
> > > >
> > > > This is probably just usable for stateless apps, but it might happen
> > > > that some apps don't really want to care about the XML at all.  They
> > > > just want an abstract view of the domain, possibly add/remove a
> device
> > > > and that's it.  We could do that as well.  I can't really tell how
> much
> > > > of a demand there is for it, though.
> > >
> > > It is safe to say that applications do not want to touch XML at all.
> > > Any non-trivial application has created an abstraction around XML,
> > > so that they have an API to express what they want, rather than
> > > manipulating of strings to format/parse XML.
> > >
> >
> > Sure, this was just meant to be a question as to whether it's worth
> > pursuing or not.  You make a good point on why it is not (at least for
> > existing apps).
> >
> > However, since this was optional, the way this would look without the
> > XML abstraction is that both input and output would be valid domain
> > definitions, ultimately resulting in something similar to virt-xml with
> > the added benefit of applying a

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]

[Gal Ben Haim]

>From lago's log, I see that lago collected the logs from the VMs using ssh
(after the test failed), which means
that the VM didn't crash.

On Wed, Apr 4, 2018 at 5:27 PM, Dan Kenigsberg  wrote:

> On Wed, Apr 4, 2018 at 4:59 PM, Barak Korren  wrote:
> > Test failed: [ 006_migrations.prepare_migration_attachments_ipv6 ]
> >
> > Link to suspected patches:
> > (Probably unrelated)
> > https://gerrit.ovirt.org/#/c/89812/1 (ovirt-engine-sdk) - examples:
> > export template to an export domain
> >
> > This seems to happen multiple times sporadically, I thought this would
> > be solved by
> > https://gerrit.ovirt.org/#/c/89781/ but it isn't.
>
> right, it is a completely unrelated issue there (with external networks).
> here, however, the host dies while setting setupNetworks of an ipv6
> address. Setup network waits for Engine's confirmation at 08:33:00,711
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1537/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/lago-
> basic-suite-4-2-host-0/_var_log/vdsm/supervdsm.log
> but kernel messages stop at 08:33:23
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1537/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/lago-
> basic-suite-4-2-host-0/_var_log/messages/*view*/
>
> Does the lago VM of this host crash? pause?
>
>
> >
> > Link to Job:
> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/
> >
> > Link to all logs:
> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1537/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/
> >
> > Error snippet from log:
> >
> > 
> >
> > Traceback (most recent call last):
> >   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
> > testMethod()
> >   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in
> runTest
> > self.test(*self.arg)
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 129, in wrapped_test
> > test()
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 59, in wrapper
> > return func(get_test_prefix(), *args, **kwargs)
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 78, in wrapper
> > prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs
> >   File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/
> ovirt-system-tests/basic-suite-4.2/test-scenarios/006_migrations.py",
> > line 139, in prepare_migration_attachments_ipv6
> > engine, host_service, MIGRATION_NETWORK, ip_configuration)
> >   File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/
> ovirt-system-tests/basic-suite-4.2/test_utils/network_utils_v4.py",
> > line 71, in modify_ip_config
> > check_connectivity=True)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
> > line 36729, in setup_networks
> > return self._internal_action(action, 'setupnetworks', None,
> > headers, query, wait)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 299, in _internal_action
> > return future.wait() if wait else future
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 55, in wait
> > return self._code(response)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 296, in callback
> > self._check_fault(response)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 132, in _check_fault
> > self._raise_error(response, body)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 118, in _raise_error
> > raise error
> > Error: Fault reason is "Operation Failed". Fault detail is "[Network
> > error during communication with the Host.]". HTTP response code is
> > 400.
> >
> >
> >
> > 
> >
> >
> >
> > --
> > Barak Korren
> > RHV DevOps team , RHCE, RHCi
> > Red Hat EMEA
> > redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> > ___
> > 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
>



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]

[Dan Kenigsberg]

On Wed, Apr 4, 2018 at 4:59 PM, Barak Korren  wrote:
> Test failed: [ 006_migrations.prepare_migration_attachments_ipv6 ]
>
> Link to suspected patches:
> (Probably unrelated)
> https://gerrit.ovirt.org/#/c/89812/1 (ovirt-engine-sdk) - examples:
> export template to an export domain
>
> This seems to happen multiple times sporadically, I thought this would
> be solved by
> https://gerrit.ovirt.org/#/c/89781/ but it isn't.

right, it is a completely unrelated issue there (with external networks).
here, however, the host dies while setting setupNetworks of an ipv6
address. Setup network waits for Engine's confirmation at 08:33:00,711
http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/artifact/exported-artifacts/basic-suit-4.2-el7/test_logs/basic-suite-4.2/post-006_migrations.py/lago-basic-suite-4-2-host-0/_var_log/vdsm/supervdsm.log
but kernel messages stop at 08:33:23
http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/artifact/exported-artifacts/basic-suit-4.2-el7/test_logs/basic-suite-4.2/post-006_migrations.py/lago-basic-suite-4-2-host-0/_var_log/messages/*view*/

Does the lago VM of this host crash? pause?


>
> Link to Job:
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/
>
> Link to all logs:
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/artifact/exported-artifacts/basic-suit-4.2-el7/test_logs/basic-suite-4.2/post-006_migrations.py/
>
> Error snippet from log:
>
> 
>
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
> testMethod()
>   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> 129, in wrapped_test
> test()
>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> 59, in wrapper
> return func(get_test_prefix(), *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> 78, in wrapper
> prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs
>   File 
> "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test-scenarios/006_migrations.py",
> line 139, in prepare_migration_attachments_ipv6
> engine, host_service, MIGRATION_NETWORK, ip_configuration)
>   File 
> "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test_utils/network_utils_v4.py",
> line 71, in modify_ip_config
> check_connectivity=True)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
> line 36729, in setup_networks
> return self._internal_action(action, 'setupnetworks', None,
> headers, query, wait)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> 299, in _internal_action
> return future.wait() if wait else future
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> 55, in wait
> return self._code(response)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> 296, in callback
> self._check_fault(response)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> 132, in _check_fault
> self._raise_error(response, body)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> 118, in _raise_error
> raise error
> Error: Fault reason is "Operation Failed". Fault detail is "[Network
> error during communication with the Host.]". HTTP response code is
> 400.
>
>
>
> 
>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> 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] [OST][HC] HE fails to deploy

[Sahina Bose]

On Tue, Apr 3, 2018 at 1:50 PM, Simone Tiraboschi 
wrote:

>
>
> On Tue, Apr 3, 2018 at 10:14 AM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Mon, Apr 2, 2018 at 4:44 PM, Sahina Bose  wrote:
>>
>>> HE fails to deploy at waiting for host to be up in the local HE VM.
>>> The setup logs does not indicate why it failed - atleast I couldn't find
>>> anything
>>>
>>
>> I see:
>>
>> "status": "install_failed"
>>
>> So I think that something went wrong with host-deploy on that host but we
>> definitively need host-deploy logs for that and they are just on the engine
>> VM.
>>
>
> According to the timestamps it could be related to:
> Apr  2 09:58:13 lago-hc-basic-suite-master-host-0 systemd: Starting Open
> vSwitch Database Unit...
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl: runuser:
> System error
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl:
> /etc/openvswitch/conf.db does not exist ... (warning).
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl: Creating empty
> database /etc/openvswitch/conf.db runuser: System error
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 ovs-ctl: [FAILED]
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
> ovsdb-server.service: control process exited, code=exited status=1
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Failed to
> start Open vSwitch Database Unit.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Unit
> ovsdb-server.service entered failed state.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
> ovsdb-server.service failed.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Cannot add
> dependency job for unit lvm2-lvmetad.socket, ignoring: Invalid request
> descriptor
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Assertion
> failed for Open vSwitch Delete Transient Ports.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
> ovsdb-server.service holdoff time over, scheduling restart.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Cannot add
> dependency job for unit lvm2-lvmetad.socket, ignoring: Unit is masked.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: start request
> repeated too quickly for ovsdb-server.service
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Failed to
> start Open vSwitch Database Unit.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd: Unit
> ovsdb-server.service entered failed state.
> Apr  2 09:58:14 lago-hc-basic-suite-master-host-0 systemd:
> ovsdb-server.service failed.
>

Does this require an update to openvswitch rpms used in suite?
Are the HE suites passing?


>
>>
>>
>>>
>>> -- Forwarded message --
>>> From: 
>>> Date: Mon, Apr 2, 2018 at 7:50 PM
>>> Subject: [oVirt Jenkins] ovirt-system-tests_hc-basic-suite-master -
>>> Build # 276 - Still Failing!
>>> To: in...@ovirt.org, sab...@redhat.com
>>>
>>>
>>> Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-sui
>>> te-master/
>>> Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-sui
>>> te-master/276/
>>> Build Number: 276
>>> Build Status:  Still Failing
>>> Triggered By: Started by timer
>>>
>>> -
>>> Changes Since Last Success:
>>> -
>>> Changes for Build #265
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>> [Sandro Bonazzola] ovirt-engine: add jobs for 4.1.10 async
>>>
>>>
>>> Changes for Build #266
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>>
>>> Changes for Build #267
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>> [Daniel Belenky] ppc repos: Use qemu EV release instead of test
>>>
>>> [Daniel Belenky] global_setup: Add generic package remove function
>>>
>>> [Daniel Belenky] Fix package verification in verify_packages
>>>
>>>
>>> Changes for Build #268
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>>
>>> Changes for Build #269
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>>
>>> Changes for Build #270
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>>
>>> Changes for Build #271
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>>
>>> Changes for Build #272
>>> [Gal Ben Haim] Check if the prefix exists before printing its size
>>>
>>>
>>> Changes for Build #273
>>> [Eitan Raviv] network: macpool: test disallowing dups while dups exist
>>>
>>> [Daniel Belenky] docker cleanup:Fix edge case for unamed containers
>>>
>>> [Daniel Belenky] nested_config: Count nesting level of options
>>>
>>> [Daniel Belenky] Introduce conditional execution in STDCI DSL
>>>
>>> [Daniel Belenky] Add OST STDCI V2 jobs
>>>
>>>
>>> Changes for Build #274
>>> [Gal Ben Haim] he-iscsi-master: Temporarily exclude in check-patch
>>>
>>>
>>> Changes for Build #275
>>> [Gal Ben Haim] he-iscsi-master: Temporarily exclude i

[ovirt-devel] [ OST Failure Report ] [ oVirt 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]

[Barak Korren]

Test failed: [ 006_migrations.prepare_migration_attachments_ipv6 ]

Link to suspected patches:
(Probably unrelated)
https://gerrit.ovirt.org/#/c/89812/1 (ovirt-engine-sdk) - examples:
export template to an export domain

This seems to happen multiple times sporadically, I thought this would
be solved by
https://gerrit.ovirt.org/#/c/89781/ but it isn't.

Link to Job:
http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/

Link to all logs:
http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/artifact/exported-artifacts/basic-suit-4.2-el7/test_logs/basic-suite-4.2/post-006_migrations.py/

Error snippet from log:



Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
testMethod()
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
129, in wrapped_test
test()
  File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
59, in wrapper
return func(get_test_prefix(), *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
78, in wrapper
prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs
  File 
"/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test-scenarios/006_migrations.py",
line 139, in prepare_migration_attachments_ipv6
engine, host_service, MIGRATION_NETWORK, ip_configuration)
  File 
"/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test_utils/network_utils_v4.py",
line 71, in modify_ip_config
check_connectivity=True)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
line 36729, in setup_networks
return self._internal_action(action, 'setupnetworks', None,
headers, query, wait)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
299, in _internal_action
return future.wait() if wait else future
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
55, in wait
return self._code(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
296, in callback
self._check_fault(response)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
132, in _check_fault
self._raise_error(response, body)
  File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
118, in _raise_error
raise error
Error: Fault reason is "Operation Failed". Fault detail is "[Network
error during communication with the Host.]". HTTP response code is
400.







-- 
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm][ci] EL7 failing for timeout lately

[Eyal Edri]

Adding infra, from infra side I'm not aware of any major changes that can
cause this to happen.
Have you considered introducing performance testing so you'll know how much
time each test take and fail/warn if it start to take much longer?

On Wed, Apr 4, 2018 at 3:35 PM, Francesco Romani  wrote:

> Hi all,
>
>
> in the last few days quite a lot of CI tests on LE7 workers failed for
> timeout. Random example:
> http://jenkins.ovirt.org/job/vdsm_4.2_check-patch-el7-x86_
> 64/246/consoleFull
>
>
> This happened both on 4.2 and on master test suite, quite often but not
> always.
>
>
> I wonder if we should just increase the timeout or if something else is
> going on.
>
>
> Thoughts?
>
> --
> Francesco Romani
> Senior SW Eng., Virtualization R&D
> Red Hat
> IRC: fromani github: @fromanirh
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 

Eyal edri


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)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [vdsm][ci] EL7 failing for timeout lately

[Francesco Romani]

Hi all,


in the last few days quite a lot of CI tests on LE7 workers failed for
timeout. Random example:
http://jenkins.ovirt.org/job/vdsm_4.2_check-patch-el7-x86_64/246/consoleFull


This happened both on 4.2 and on master test suite, quite often but not
always.


I wonder if we should just increase the timeout or if something else is
going on.


Thoughts?

-- 
Francesco Romani
Senior SW Eng., Virtualization R&D
Red Hat
IRC: fromani github: @fromanirh

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

Re: [ovirt-devel] oVirt log analyzer

[Milan Zamazal]

Piotr Kliczewski  writes:

> On Wed, Apr 4, 2018 at 10:47 AM, Milan Zamazal  wrote:
>> Barak Korren  writes:
>>
>
>>> Right now, when a test fails in OST - al you get is the traceback from
>>> nose of the oVirt API cll you've made. For some tests additional
>>> information is provided by having nise collect it from  STDOUT.
>>>
>>> It could be very useful if we could use some information about the API
>>> call that had been made, and use it to extract relevant information
>>> about the call from the vdms and engine logs,
>>>
>>> Can ovirt-log-analyzer be used for that?
>>
>> Maybe, but not out of the box.  It can parse logs and find some
>> relations between Engine and Vdsm logs, so it might be extended to do
>> that.  However it's more focused on guess work.  Depending on kind of
>> the information to be provided there could be simpler ways to get it.
>
> Is correlation id not enough to find the relations?

It is enough to find relations between API calls and something like grep
may be easier to use for that than ovirt-log-analyzer.  Again, it
depends on what kind of information should be provided.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt log analyzer

[Piotr Kliczewski]

On Wed, Apr 4, 2018 at 10:47 AM, Milan Zamazal  wrote:
> Barak Korren  writes:
>
>> Right now, when a test fails in OST - al you get is the traceback from
>> nose of the oVirt API cll you've made. For some tests additional
>> information is provided by having nise collect it from  STDOUT.
>>
>> It could be very useful if we could use some information about the API
>> call that had been made, and use it to extract relevant information
>> about the call from the vdms and engine logs,
>>
>> Can ovirt-log-analyzer be used for that?
>
> Maybe, but not out of the box.  It can parse logs and find some
> relations between Engine and Vdsm logs, so it might be extended to do
> that.  However it's more focused on guess work.  Depending on kind of
> the information to be provided there could be simpler ways to get it.

Is correlation id not enough to find the relations?

> ___
> 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] oVirt log analyzer

[Milan Zamazal]

Barak Korren  writes:

> Right now, when a test fails in OST - al you get is the traceback from
> nose of the oVirt API cll you've made. For some tests additional
> information is provided by having nise collect it from  STDOUT.
>
> It could be very useful if we could use some information about the API
> call that had been made, and use it to extract relevant information
> about the call from the vdms and engine logs,
>
> Can ovirt-log-analyzer be used for that?

Maybe, but not out of the box.  It can parse logs and find some
relations between Engine and Vdsm logs, so it might be extended to do
that.  However it's more focused on guess work.  Depending on kind of
the information to be provided there could be simpler ways to get it.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel