date:20170518

Re: [ovirt-devel] ovirt-provider-ovn - appliance inclusion / default enablement

2017-05-18 Thread Marcin Mirecki

If the decision is to not add the provider to ovirt-appliance,
we will need to disable ovn installation during ovirt-appliance related
tests:

https://gerrit.ovirt.org/#/c/76998/

On Thu, May 18, 2017 at 4:47 PM, Marcin Mirecki  wrote:

> The size of the required components:
>
> Name   : openvswitch  Size: 11 M
> Name   : openvswitch-ovn-common  Size: 2.8 M
> Name   : openvswitch-ovn-hostSize: 1.9 M
> Name   : ovirt-provider-ovn  Size: 224 k
> Name   : python-openvswitch  Size: 821 k
>
> about 17M total
>
> On Thu, May 18, 2017 at 3:26 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Wed, May 17, 2017 at 2:35 PM, Yedidyah Bar David 
>> wrote:
>>
>>> On Wed, May 17, 2017 at 2:54 PM, Dan Kenigsberg 
>>> wrote:
>>> > On Wed, May 17, 2017 at 12:23 PM, Yedidyah Bar David 
>>> wrote:
>>> >> On Wed, May 17, 2017 at 11:42 AM, Dan Kenigsberg 
>>> wrote:
>>> >>> On Wed, May 17, 2017 at 10:44 AM, Yedidyah Bar David <
>>> d...@redhat.com> wrote:
>>>  On Wed, May 17, 2017 at 9:38 AM, Dan Kenigsberg 
>>> wrote:
>>> > On Tue, May 16, 2017 at 6:56 PM, Sandro Bonazzola <
>>> sbona...@redhat.com> wrote:
>>> >>
>>> >> Hi,
>>> >> with https://gerrit.ovirt.org/76855 it's requested to increase
>>> the appliance size by adding ovirt-provider-ovn and its dependencies.
>>> >>
>>> >> This raise a few questions.
>>> >> The support for ovirt-provider-ovn is enabled by default in
>>> engine-setup and going to be installed by default in the appliance so we're
>>> pushing to use it.
>>> >> Why not requiring it at ovirt-engine spec file level?
>>> >> Answer given in the commit message of above patch is:
>>> >>
>>> >> We do not want to have a hard dependency in the
>>> >> form of an rpm require.
>>> >> OVN and openvswitch are relatively heavy and complex,
>>> >> and are still experimental. We would not want to
>>> >> force everybody to pull them onto any Engine host.
>>> >>
>>> >> So why adding it to the appliance, which is the default for
>>> hosted engine which is our recommeded way to deploy oVirt, and enable it by
>>> default?
>>> >>
>>> >> How this differs from DWH? ovirt-engine requires
>>> ovirt-engine-setup which requires ovirt-engine-dwh setup which requires
>>> ovirt-engine-dwh.
>>> >> Why can't we just require ovirt-provider-ovn in ovirt-engine
>>> instead of tweaking the appliance?
>>> >>
>>> >> If we decide it's not mandatory, why not make the default to not
>>> enabling it in engine-setup and avoid to add it to the appliance?
>>> >> Being optional, adding it collides with Bug 1401931 - [RFE]
>>> reduce the size of the appliance
>>> >
>>> > Much like with DWH, I can envisage a use case where
>>> ovirt-provider-ovn
>>> > sits on a remote host, rather than on Engine's. However, the
>>> default
>>> > use case is to place them on the same host.
>>> >
>>> > I thought that it would be a good idea to include OVN on the
>>> > appliance, as a means to showcase this new and exciting feature of
>>> > oVirt. However, it is not a must. We can say that we'd like to keep
>>> > the appliance small; if someone wants to use OVN with it, let them
>>> run
>>> > ovirt-engine-setup manually, and pull in the dependencies.
>>> 
>>>  The appliance is assumed to (soon?) be our standard installation
>>> flow,
>>>  not a way to showcase things. For the latter, you might want to add
>>> ovn
>>>  to ovirt-live or to the ovirt demo tool [1] (not yet released IIUC).
>>> 
>>>  [1] https://trello.com/b/wocfflzf/sales-demo-tool-lago-based
>>> 
>>> >
>>> > For this we'd need to flip the default, and not install OVN when
>>> the
>>> > appliance is created, and skip OVN test in the offline test suite.
>>> 
>>>  +1
>>> >>>
>>> >>> Could you point us to the answer file used for appliance creation?
>>> >>
>>> >> Do you want to keep the default True for non-appliance? My +1 above
>>> >> was also for reverting the default, not only in appliance.
>>> >
>>> > Oh. I still want to have OVN by default for non-appliance. I like this
>>> > feature, and I want to entice people to use it.
>>>
>>> I think that Sandro's question above applies equally well to the
>>> non-appliance usecase. If it's good enough to be the default for
>>> non-appliance, might as well be so for the appliance as well. If
>>> it's not good enough for the appliance, perhaps default to No also
>>> for non-appliance.
>>>
>>> >
>>> > For appliance I understand that we have a size limitation, so ok, let
>>> > us not bloat it up.
>>>
>>> What's the impact on size? For the appliance image and for the
>>> eventually-installed machine?
>>>
>>> I do not think the impact on appliance size is the major question here,
>>> but whether we

Re: [ovirt-devel] ovirt-provider-ovn - appliance inclusion / default enablement

2017-05-18 Thread Marcin Mirecki

The size of the required components:

Name   : openvswitch  Size: 11 M
Name   : openvswitch-ovn-common  Size: 2.8 M
Name   : openvswitch-ovn-hostSize: 1.9 M
Name   : ovirt-provider-ovn  Size: 224 k
Name   : python-openvswitch  Size: 821 k

about 17M total

On Thu, May 18, 2017 at 3:26 PM, Simone Tiraboschi 
wrote:

>
>
> On Wed, May 17, 2017 at 2:35 PM, Yedidyah Bar David 
> wrote:
>
>> On Wed, May 17, 2017 at 2:54 PM, Dan Kenigsberg 
>> wrote:
>> > On Wed, May 17, 2017 at 12:23 PM, Yedidyah Bar David 
>> wrote:
>> >> On Wed, May 17, 2017 at 11:42 AM, Dan Kenigsberg 
>> wrote:
>> >>> On Wed, May 17, 2017 at 10:44 AM, Yedidyah Bar David 
>> wrote:
>>  On Wed, May 17, 2017 at 9:38 AM, Dan Kenigsberg 
>> wrote:
>> > On Tue, May 16, 2017 at 6:56 PM, Sandro Bonazzola <
>> sbona...@redhat.com> wrote:
>> >>
>> >> Hi,
>> >> with https://gerrit.ovirt.org/76855 it's requested to increase
>> the appliance size by adding ovirt-provider-ovn and its dependencies.
>> >>
>> >> This raise a few questions.
>> >> The support for ovirt-provider-ovn is enabled by default in
>> engine-setup and going to be installed by default in the appliance so we're
>> pushing to use it.
>> >> Why not requiring it at ovirt-engine spec file level?
>> >> Answer given in the commit message of above patch is:
>> >>
>> >> We do not want to have a hard dependency in the
>> >> form of an rpm require.
>> >> OVN and openvswitch are relatively heavy and complex,
>> >> and are still experimental. We would not want to
>> >> force everybody to pull them onto any Engine host.
>> >>
>> >> So why adding it to the appliance, which is the default for hosted
>> engine which is our recommeded way to deploy oVirt, and enable it by
>> default?
>> >>
>> >> How this differs from DWH? ovirt-engine requires
>> ovirt-engine-setup which requires ovirt-engine-dwh setup which requires
>> ovirt-engine-dwh.
>> >> Why can't we just require ovirt-provider-ovn in ovirt-engine
>> instead of tweaking the appliance?
>> >>
>> >> If we decide it's not mandatory, why not make the default to not
>> enabling it in engine-setup and avoid to add it to the appliance?
>> >> Being optional, adding it collides with Bug 1401931 - [RFE] reduce
>> the size of the appliance
>> >
>> > Much like with DWH, I can envisage a use case where
>> ovirt-provider-ovn
>> > sits on a remote host, rather than on Engine's. However, the default
>> > use case is to place them on the same host.
>> >
>> > I thought that it would be a good idea to include OVN on the
>> > appliance, as a means to showcase this new and exciting feature of
>> > oVirt. However, it is not a must. We can say that we'd like to keep
>> > the appliance small; if someone wants to use OVN with it, let them
>> run
>> > ovirt-engine-setup manually, and pull in the dependencies.
>> 
>>  The appliance is assumed to (soon?) be our standard installation
>> flow,
>>  not a way to showcase things. For the latter, you might want to add
>> ovn
>>  to ovirt-live or to the ovirt demo tool [1] (not yet released IIUC).
>> 
>>  [1] https://trello.com/b/wocfflzf/sales-demo-tool-lago-based
>> 
>> >
>> > For this we'd need to flip the default, and not install OVN when the
>> > appliance is created, and skip OVN test in the offline test suite.
>> 
>>  +1
>> >>>
>> >>> Could you point us to the answer file used for appliance creation?
>> >>
>> >> Do you want to keep the default True for non-appliance? My +1 above
>> >> was also for reverting the default, not only in appliance.
>> >
>> > Oh. I still want to have OVN by default for non-appliance. I like this
>> > feature, and I want to entice people to use it.
>>
>> I think that Sandro's question above applies equally well to the
>> non-appliance usecase. If it's good enough to be the default for
>> non-appliance, might as well be so for the appliance as well. If
>> it's not good enough for the appliance, perhaps default to No also
>> for non-appliance.
>>
>> >
>> > For appliance I understand that we have a size limitation, so ok, let
>> > us not bloat it up.
>>
>> What's the impact on size? For the appliance image and for the
>> eventually-installed machine?
>>
>> I do not think the impact on appliance size is the major question here,
>> but whether we really expect most users to use OVN. But I might be
>> surprised...
>>
>>
> Now we have a bug to track it:
> https://bugzilla.redhat.com/show_bug.cgi?id=1452131
>
>
>> >
>> > I hope you are also fine with disabling ovn in the following answer
>> file.
>> >
>> >>
>> >> The appliance-supplied answer file seems is:
>> >>
>> >> https://gerrit.ovirt.org/gitweb?p=ovirt-appliance.git;a=
>>

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 14/05/2017 ] [ test-repo_ovirt_experimental_master ]

2017-05-18 Thread Piotr Kliczewski

Yevgeny,

There is message id which matches request and response but in this
case I made an assumption about setupNetworks being exclusive
operation.
The following setupNetwoks was the last one which was last executed.

Thanks,
Piotr

On Thu, May 18, 2017 at 1:28 PM, Yevgeny Zaspitsky  wrote:
> Piotr,
>
> How do you identify the connection between the 2 message, why do you think
> that the timeout is related to the first message you've mentioned?
>
> Regards,
> Yevgeny
>
> On Mon, May 15, 2017 at 12:40 PM, Piotr Kliczewski
>  wrote:
>>
>> I agree with Nir that the above issue is not related to the job failure.
>>
>> I see that there is a timeout for:
>>
>> 2017-05-14 04:10:04,215-04 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.StompCommonClient]
>> (org.ovirt.thread.pool-7-thread-12) [] Message sent: SEND
>> destination:jms.topic.vdsm_requests
>> content-length:377
>> reply-to:jms.topic.vdsm_responses
>>
>> > Host.setupNetworks, params: {networks={Migration_Net={vlan=200,
>> ipv6autoconf=false, nic=eth0, bridged=false, dhcpv6=false, mtu=1500,
>> ipv6addr=2001:0db8:85a3:::574c:14ea:0a02/64, switch=legacy}},
>> bondings={}, options={connectivityTimeout=120,
>> connectivityCheck=true}}>
>>
>>
>> and the timeout occurred at:
>>
>> 2017-05-14 04:10:07,535-04 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
>> (ResponseWorker) [] Message received:
>>
>> {"jsonrpc":"2.0","error":{"code":"lago-basic-suite-master-host1:286640862","message":"Vds
>> timeout occured"},"id":null}
>>
>> I see in supervdsm log:
>>
>> MainProcess|jsonrpc/1::INFO::2017-05-14
>> 04:10:05,566::netconfpersistence::52::root::(setNetwork) Adding
>> network Migration_Net({u'ipv6autoconf': False, 'nameservers': [],
>> u'nic': u'eth0', u'vlan': 200, u'mtu': 1500, u'switch': u'legacy',
>> u'dhcpv6': False, u'bridged': False, u'ipv6addr':
>> u'2001:0db8:85a3:::574c:14ea:0a02/64', 'defaultRoute': False,
>> 'bootproto': 'none'})
>> ...
>> MainProcess|jsonrpc/1::WARNING::2017-05-14
>> 04:10:05,580::ifcfg::247::root::(_addSourceRoute) Invalid input for
>> source routing: name=eth0.200, addr=None, netmask=None, gateway=None
>> netlink/events::DEBUG::2017-05-14
>> 04:10:05,581::concurrent::184::root::(run) START thread
>>  (func=> method Monitor._scan of > at 0x7f2c8c01ebd0>>, args=(), kwargs={})
>> MainProcess|jsonrpc/1::WARNING::2017-05-14
>> 04:10:05,581::ifcfg::894::root::(_ignore_missing_device) eth0.200
>> didn't exist (yet) and so IPv6 wasn't enabled.
>>
>> My question is why only 3 seconds to timeout setupNetworks.
>>
>>
>>
>> I found one more exception not related to the above issue which we should
>> fix:
>>
>> 2017-05-14 04:08:08,924-04 DEBUG
>> [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
>> (DefaultQuartzScheduler10) [58fd90c1] Exception:
>> java.lang.reflect.InvocationTargetException
>> at sun.reflect.GeneratedMethodAccessor178.invoke(Unknown Source)
>> [:1.8.0_131]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.8.0_131]
>> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
>> at
>> org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(JobWrapper.java:83)
>> [scheduler.jar:]
>> at
>> org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:55)
>> [scheduler.jar:]
>> at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> [rt.jar:1.8.0_131]
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> [rt.jar:1.8.0_131]
>> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
>> Caused by: java.lang.NullPointerException
>> at
>> org.ovirt.engine.core.vdsbroker.monitoring.VmStatsRefresher.lambda$processDevices$0(VmStatsRefresher.java:44)
>> [vdsbroker.jar:]
>> at
>> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
>> [rt.jar:1.8.0_131]
>> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
>> [rt.jar:1.8.0_131]
>> at
>>

Re: [ovirt-devel] ovirt-provider-ovn - appliance inclusion / default enablement

2017-05-18 Thread Simone Tiraboschi

On Wed, May 17, 2017 at 2:35 PM, Yedidyah Bar David  wrote:

> On Wed, May 17, 2017 at 2:54 PM, Dan Kenigsberg  wrote:
> > On Wed, May 17, 2017 at 12:23 PM, Yedidyah Bar David 
> wrote:
> >> On Wed, May 17, 2017 at 11:42 AM, Dan Kenigsberg 
> wrote:
> >>> On Wed, May 17, 2017 at 10:44 AM, Yedidyah Bar David 
> wrote:
>  On Wed, May 17, 2017 at 9:38 AM, Dan Kenigsberg 
> wrote:
> > On Tue, May 16, 2017 at 6:56 PM, Sandro Bonazzola <
> sbona...@redhat.com> wrote:
> >>
> >> Hi,
> >> with https://gerrit.ovirt.org/76855 it's requested to increase the
> appliance size by adding ovirt-provider-ovn and its dependencies.
> >>
> >> This raise a few questions.
> >> The support for ovirt-provider-ovn is enabled by default in
> engine-setup and going to be installed by default in the appliance so we're
> pushing to use it.
> >> Why not requiring it at ovirt-engine spec file level?
> >> Answer given in the commit message of above patch is:
> >>
> >> We do not want to have a hard dependency in the
> >> form of an rpm require.
> >> OVN and openvswitch are relatively heavy and complex,
> >> and are still experimental. We would not want to
> >> force everybody to pull them onto any Engine host.
> >>
> >> So why adding it to the appliance, which is the default for hosted
> engine which is our recommeded way to deploy oVirt, and enable it by
> default?
> >>
> >> How this differs from DWH? ovirt-engine requires ovirt-engine-setup
> which requires ovirt-engine-dwh setup which requires ovirt-engine-dwh.
> >> Why can't we just require ovirt-provider-ovn in ovirt-engine
> instead of tweaking the appliance?
> >>
> >> If we decide it's not mandatory, why not make the default to not
> enabling it in engine-setup and avoid to add it to the appliance?
> >> Being optional, adding it collides with Bug 1401931 - [RFE] reduce
> the size of the appliance
> >
> > Much like with DWH, I can envisage a use case where
> ovirt-provider-ovn
> > sits on a remote host, rather than on Engine's. However, the default
> > use case is to place them on the same host.
> >
> > I thought that it would be a good idea to include OVN on the
> > appliance, as a means to showcase this new and exciting feature of
> > oVirt. However, it is not a must. We can say that we'd like to keep
> > the appliance small; if someone wants to use OVN with it, let them
> run
> > ovirt-engine-setup manually, and pull in the dependencies.
> 
>  The appliance is assumed to (soon?) be our standard installation flow,
>  not a way to showcase things. For the latter, you might want to add
> ovn
>  to ovirt-live or to the ovirt demo tool [1] (not yet released IIUC).
> 
>  [1] https://trello.com/b/wocfflzf/sales-demo-tool-lago-based
> 
> >
> > For this we'd need to flip the default, and not install OVN when the
> > appliance is created, and skip OVN test in the offline test suite.
> 
>  +1
> >>>
> >>> Could you point us to the answer file used for appliance creation?
> >>
> >> Do you want to keep the default True for non-appliance? My +1 above
> >> was also for reverting the default, not only in appliance.
> >
> > Oh. I still want to have OVN by default for non-appliance. I like this
> > feature, and I want to entice people to use it.
>
> I think that Sandro's question above applies equally well to the
> non-appliance usecase. If it's good enough to be the default for
> non-appliance, might as well be so for the appliance as well. If
> it's not good enough for the appliance, perhaps default to No also
> for non-appliance.
>
> >
> > For appliance I understand that we have a size limitation, so ok, let
> > us not bloat it up.
>
> What's the impact on size? For the appliance image and for the
> eventually-installed machine?
>
> I do not think the impact on appliance size is the major question here,
> but whether we really expect most users to use OVN. But I might be
> surprised...
>
>
Now we have a bug to track it:
https://bugzilla.redhat.com/show_bug.cgi?id=1452131


> >
> > I hope you are also fine with disabling ovn in the following answer file.
> >
> >>
> >> The appliance-supplied answer file seems is:
> >>
> >> https://gerrit.ovirt.org/gitweb?p=ovirt-appliance.git;
> a=blob;f=engine-appliance/data/ovirt-engine-answers;h=
> 2881af6563297a7a3d220dfe479d39f88c12ca46;hb=HEAD
> >>
> >> When hosted-engine --deploy is using the appliance, and if the user
> >> asks to run engine-setup automatically, it uses above file,
> >> but also adds another file, auto-generated, see here:
> >>
> >> https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-
> setup.git;a=blob;f=src/plugins/gr-he-common/vm/cloud_init.py;h=
> 0a20f946d65199423c99769ab51e4fe092465e96;hb=HEAD#l1018
> >>
> >> None of them has the answer for OVN.

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 14/05/2017 ] [ test-repo_ovirt_experimental_master ]

2017-05-18 Thread Yevgeny Zaspitsky

Piotr,

How do you identify the connection between the 2 message, why do you think
that the timeout is related to the first message you've mentioned?

Regards,
Yevgeny

On Mon, May 15, 2017 at 12:40 PM, Piotr Kliczewski <
piotr.kliczew...@gmail.com> wrote:

> I agree with Nir that the above issue is not related to the job failure.
>
> I see that there is a timeout for:
>
> 2017-05-14 04:10:04,215-04 DEBUG
> [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.StompCommonClient]
> (org.ovirt.thread.pool-7-thread-12) [] Message sent: SEND
> destination:jms.topic.vdsm_requests
> content-length:377
> reply-to:jms.topic.vdsm_responses
>
>  Host.setupNetworks, params: {networks={Migration_Net={vlan=200,
> ipv6autoconf=false, nic=eth0, bridged=false, dhcpv6=false, mtu=1500,
> ipv6addr=2001:0db8:85a3:::574c:14ea:0a02/64, switch=legacy}},
> bondings={}, options={connectivityTimeout=120,
> connectivityCheck=true}}>
>
>
> and the timeout occurred at:
>
> 2017-05-14 04:10:07,535-04 DEBUG
> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
> (ResponseWorker) [] Message received:
> {"jsonrpc":"2.0","error":{"code":"lago-basic-suite-
> master-host1:286640862","message":"Vds
> timeout occured"},"id":null}
>
> I see in supervdsm log:
>
> MainProcess|jsonrpc/1::INFO::2017-05-14
> 04:10:05,566::netconfpersistence::52::root::(setNetwork) Adding
> network Migration_Net({u'ipv6autoconf': False, 'nameservers': [],
> u'nic': u'eth0', u'vlan': 200, u'mtu': 1500, u'switch': u'legacy',
> u'dhcpv6': False, u'bridged': False, u'ipv6addr':
> u'2001:0db8:85a3:::574c:14ea:0a02/64', 'defaultRoute': False,
> 'bootproto': 'none'})
> ...
> MainProcess|jsonrpc/1::WARNING::2017-05-14
> 04:10:05,580::ifcfg::247::root::(_addSourceRoute) Invalid input for
> source routing: name=eth0.200, addr=None, netmask=None, gateway=None
> netlink/events::DEBUG::2017-05-14
> 04:10:05,581::concurrent::184::root::(run) START thread
>  (func= method Monitor._scan of  at 0x7f2c8c01ebd0>>, args=(), kwargs={})
> MainProcess|jsonrpc/1::WARNING::2017-05-14
> 04:10:05,581::ifcfg::894::root::(_ignore_missing_device) eth0.200
> didn't exist (yet) and so IPv6 wasn't enabled.
>
> My question is why only 3 seconds to timeout setupNetworks.
>
>
>
> I found one more exception not related to the above issue which we should
> fix:
>
> 2017-05-14 04:08:08,924-04 DEBUG
> [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
> (DefaultQuartzScheduler10) [58fd90c1] Exception:
> java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor178.invoke(Unknown Source)
> [:1.8.0_131]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_131]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
> at org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(
> JobWrapper.java:83)
> [scheduler.jar:]
> at org.ovirt.engine.core.utils.timer.JobWrapper.execute(
> JobWrapper.java:55)
> [scheduler.jar:]
> at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Caused by: java.lang.NullPointerException
> at org.ovirt.engine.core.vdsbroker.monitoring.VmStatsRefresher.lambda$
> processDevices$0(VmStatsRefresher.java:44)
> [vdsbroker.jar:]
> at java.util.stream.ReferencePipeline$2$1.accept(
> ReferencePipeline.java:174)
> [rt.jar:1.8.0_131]
> at java.util.stream.ReferencePipeline$3$1.accept(
> ReferencePipeline.java:193)
> [rt.jar:1.8.0_131]
> at java.util.stream.ReferencePipeline$2$1.accept(
> ReferencePipeline.java:175)
> [rt.jar:1.8.0_131]
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.
> java:1374)
> [rt.jar:1.8.0_131]
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> [rt.jar:1.8.0_131]
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(
> AbstractPipeline.java:471)
> [rt.jar:1.8.0_131]
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(
> ForEachOps.java:151)
> [rt.jar:1.8.0_131]
> at java.util.stream.ForEachOps$ForEachOp$OfRef.
> evaluateSequential(ForEachOps.java:174)
> [rt.jar:1.8.0_131]
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [rt.jar:1.8.0_131]
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> [rt.jar:1.8.0_131]
> at org.ovirt.engine.core.vdsbroker.monitoring.VmStatsRefresher.
> processDevices(VmStatsRefresher.java:46)
> [vdsbroker.jar:]
> at org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher.poll(
>

[ovirt-devel] Fwd: UPDATE: Bugzilla 5 beta server is back online

2017-05-18 Thread Sandro Bonazzola

-- Forwarded message --
From: Christine Freitas 
Date: Mon, May 15, 2017 at 6:03 PM
Subject: UPDATE: Bugzilla 5 beta server is back online

Hello All,

The Bugzilla 5 beta server [1] is back online.

We encourage you to test your current scripts and take part in the beta
discussions on the Fedora development list [2]. Partners and customers may
also use their existing communications channels to share feedback or
questions. We've extended the beta window and ask that you provide feedback
or questions by Wednesday, June 14th.

The official release date for Bugzilla 5 will be determined based on the
beta feedback. We will communicate to you as the beta continues to progress.

For more information refer to:

https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html

https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html

https://beta-bugzilla.redhat.com/page.cgi?id=faq.html

https://beta-bugzilla.redhat.com/docs/en/html/using/index.html

https://beta-bugzilla.redhat.com/docs/en/html/api/index.html

Cheers, the Red Hat Bugzilla team.

1: https://beta-bugzilla.redhat.com/

2: https://lists.fedoraproject.org/archives/list/devel%40lists.
fedoraproject.org/

-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

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

Re: [ovirt-devel] ovirt-provider-ovn - appliance inclusion / default enablement

Re: [ovirt-devel] ovirt-provider-ovn - appliance inclusion / default enablement

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 14/05/2017 ] [ test-repo_ovirt_experimental_master ]

Re: [ovirt-devel] ovirt-provider-ovn - appliance inclusion / default enablement

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 14/05/2017 ] [ test-repo_ovirt_experimental_master ]

[ovirt-devel] Fwd: UPDATE: Bugzilla 5 beta server is back online

6 matches

Site Navigation

Mail list logo

Footer information