IO Threads + 3.6 Second Alpha Release
by Roman Nikolayevich Drovalev
Ýòî ñîîáùåíèå èç íåñêîëüêèõ ÷àñòåé â ôîðìàòå MIME.
--=_alternative 00459B0D43257E74_=
Content-Type: text/plain; charset="US-ASCII"
Hi,
This functions (IO Threads) is present in 3.6 Second Alpha Release oVirt
version?
http://www.ovirt.org/Features/IOThreads_Support
Thanks,
Drovalev Roman
--=_alternative 00459B0D43257E74_=
Content-Type: text/html; charset="US-ASCII"
<font size=2 face="sans-serif">Hi, </font>
<br>
<br><font size=2 face="sans-serif">This functions (IO Threads) is present
in 3.6 </font><font size=2 face="sans-serif">Second Alpha Release </font><font size=2 face="sans-serif"> oVirt
version?</font>
<br>
<br><a href=http://www.ovirt.org/Features/IOThreads_Support><font size=2 face="sans-serif">http://www.ovirt.org/Features/IOThreads_Support</font></a>
<br>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Drovalev Roman</font>
<br>
--=_alternative 00459B0D43257E74_=--
9 years, 4 months
ovirt-engine-3.5.4 branch created
by Sandro Bonazzola
Hi,
just a quick note reminding that ovirt-engine 3.5.4 branch has been created today.
Any further patch targeted 3.5.4 must be cherry-picked there too.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 5 months
Upgrade to wildfly problem
by Alexander Wels
Hi,
I followed the upgrade to wildfly steps here [1]. And everything worked as
expected. I was able to compile/run/update database without issues. However
now when I start the engine, everything appears to work but I am getting the
following stack trace over and over and over again in my engine log.
2015-06-29 11:47:44,240 WARN [org.ovirt.engine.core.vdsbroker.VdsManager]
(DefaultQuartzScheduler_Worker-39) [] Failed to refresh VDS , vds = 'host1' :
'932f05b4-e3b0-4e9a-ab99-77ff749138b3', error = 'No enum constant
org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.1',
continuing.
2015-06-29 11:47:44,241 ERROR [org.ovirt.engine.core.vdsbroker.VdsManager]
(DefaultQuartzScheduler_Worker-39) [] Exception:
java.lang.IllegalArgumentException: No enum constant
org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.1
at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_79]
at
org.ovirt.engine.core.common.businessentities.network.NetworkBootProtocol.valueOf(NetworkBootProtocol.java:6)
[common.jar:]
at
org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl$NetworkAttachmentRowMapper.mapRow(NetworkAttachmentDaoDbFacadeImpl.java:96)
[dal.jar:]
at
org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl$NetworkAttachmentRowMapper.mapRow(NetworkAttachmentDaoDbFacadeImpl.java:79)
[dal.jar:]
at
org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:92)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.RowMapperResultSetExtractor.extractData(RowMapperResultSetExtractor.java:1)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:649)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:637)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:666)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:706)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.executeCallInternal(PostgresDbEngineDialect.java:154)
[dal.jar:]
at
org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall.doExecute(PostgresDbEngineDialect.java:120)
[dal.jar:]
at
org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:181)
[spring-jdbc.jar:3.1.1.RELEASE]
at
org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:147)
[dal.jar:]
at
org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeReadList(SimpleJdbcCallsHandler.java:109)
[dal.jar:]
at
org.ovirt.engine.core.dao.network.NetworkAttachmentDaoDbFacadeImpl.getAllForHost(NetworkAttachmentDaoDbFacadeImpl.java:40)
[dal.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkAttachmentsPersister.persistNetworkAttachments(HostNetworkAttachmentsPersister.java:69)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistTopology(HostNetworkTopologyPersisterImpl.java:280)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistAndEnforceNetworkCompliance(HostNetworkTopologyPersisterImpl.java:85)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.HostNetworkTopologyPersisterImpl.persistAndEnforceNetworkCompliance(HostNetworkTopologyPersisterImpl.java:141)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:666)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.HostMonitoring.beforeFirstRefreshTreatment(HostMonitoring.java:706)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.HostMonitoring.refreshVdsRunTimeInfo(HostMonitoring.java:128)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.HostMonitoring.refresh(HostMonitoring.java:84)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:215)
[vdsbroker.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_79]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_79]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_79]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_79]
at
org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(JobWrapper.java:81)
[scheduler.jar:]
at
org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:52)
[scheduler.jar:]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]
at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)
[quartz.jar:]
After some debugging it appears that the query from the database returns "1"
as the value (which is correct as that is the value in the database). But then
the NetworkBootProtocol.forValue fails due to the possible values being
"NONE", "DHCP", "STATIC". Looking at the stored procedure there doesn't seem
to be any translation between 1 and DHCP, so it makes sense for the failure. I
compared the stored procedure to a clean new database and they are identical,
so I am assuming my database is fine in that regard.
If I modify the code to use NetworkBootProtocol.forValue instead of valueOf it
works fine, but the valueOf code has been in there for a long time so if that
was broken it would have been noticed a long time ago. I am out of thoughts,
can anyone help me figure out what is going on?
Thanks,
Alexander
[1] http://lists.ovirt.org/pipermail/devel/2015-June/010832.html
9 years, 5 months
Re: [ovirt-devel] [TICKET] failing gluster tests -- RefreshGlusterVolumeDetailsCommandTest
by Doron Fediuck
Adding rhev-gluster.
Vijay / Sahina can you please review?
On Jun 26, 2015 12:12, Eyal Edri <eedri(a)redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> > To: "Doron Fediuck" <dfediuck(a)redhat.com>, "Greg Sheremeta" <gshereme(a)redhat.com>, "infra" <infra(a)ovirt.org>,
> > devel(a)ovirt.org, "Sahina Bose" <sabose(a)redhat.com>
> > Sent: Friday, June 26, 2015 10:55:51 AM
> > Subject: Re: [ovirt-devel] [TICKET] failing gluster tests -- RefreshGlusterVolumeDetailsCommandTest
> >
> > Il 25/06/2015 17:53, Doron Fediuck ha scritto:
> > > Sahina, any idea?
> > >
> > > On 25/06/15 18:06, Greg Sheremeta wrote:
> > >> These tests appear to be randomly failing in Jenkins. Was this a
> > >> memory issue? Pretty odd error -- "Could not initialize class" --
> > >> never seen that one before.
> > >>
> > >> It worked on a dependent patch's build, and I didn't touch any
> > >> gluster stuff.
> > >>
> > >> http://jenkins.ovirt.org/job/ovirt-engine_master_unit-tests_gerrit/40725/...
> > >>
> > >> Thanks,
> > >> Greg
> > >>
> > >>
> > >> 15:56:32 Results :
> > >> 15:56:32
> > >> 15:56:32 Tests in error:
> > >> 15:56:32
> > >> org.ovirt.engine.core.bll.gluster.RefreshGlusterVolumeDetailsCommandTest
> > >> 15:56:32
> > >> testRefreshLightWeight(org.ovirt.engine.core.bll.gluster.GlusterSyncJobTest):
> > >> Could not initialize class
> > >> org.ovirt.engine.core.bll.gluster.GlusterSyncJob
> > >> 15:56:32
> > >> testRefreshHeavyWeightFor31(org.ovirt.engine.core.bll.gluster.GlusterSyncJobTest):
> > >> Could not initialize class
> > >> org.ovirt.engine.core.bll.gluster.GlusterSyncJob
> > >> 15:56:32
> > >> testRefreshHeavyWeightFor32(org.ovirt.engine.core.bll.gluster.GlusterSyncJobTest):
> > >> Could not initialize class
> > >> org.ovirt.engine.core.bll.gluster.GlusterSyncJob
> > >> 15:56:32
> > >> testRefreshLightWeightFor33(org.ovirt.engine.core.bll.gluster.GlusterSyncJobTest):
> > >> Could not initialize class
> > >> org.ovirt.engine.core.bll.gluster.GlusterSyncJob
> > >> 15:56:32
> > >> 15:56:32 Tests run: 2341, Failures: 0, Errors: 5, Skipped: 6
> > >> 15:56:32
> >
> > Just sent an email about the same error. It's reproducible near to 100%
> > please address as soon as possible.
> >
>
> this was the latest gluster patch related: https://gerrit.ovirt.org/#/c/42863/
> might worth to revert until fixed.
>
>
>
> >
> > >>
> > >> Greg Sheremeta
> > >> Red Hat, Inc.
> > >> Sr. Software Engineer, RHEV
> > >> Cell: 919-807-1086
> > >> gshereme(a)redhat.com
> > >> _______________________________________________
> > >> Devel mailing list
> > >> Devel(a)ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/devel
> > >>
> > >
> > > _______________________________________________
> > > Devel mailing list
> > > Devel(a)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
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> >
>
> --
> Eyal Edri
> Supervisor, RHEV CI
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
9 years, 5 months
Fwd: Orphaning jasperreports
by Yedidyah Bar David
It seems like the engine depends on jasperreports (not jasperreports-server,
needed by ovirt-reports - this one we package in ovirt repos).
Not sure the following is the only path:
ovirt-engine requires openstack-java-resteasy-connector >= 3.1.1
openstack-java-resteasy-connector requires mvn(org.jboss.resteasy:resteasy-jaxrs)
mvn(org.jboss.resteasy:resteasy-jaxrs) is provided by resteasy
resteasy requires mvn(org.springframework:spring-webmvc)
mvn(org.springframework:spring-webmvc) is provided by springframework-webmvc
springframework-webmvc requires mvn(net.sf.jasperreports:jasperreports)
mvn(net.sf.jasperreports:jasperreports) is provided by jasperreports
FYI.
Best,
--
Didi
----- Forwarded Message -----
From: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
To: "Shirly Radco" <sradco(a)redhat.com>, "Yedidyah Bar David" <didi(a)redhat.com>, "Yaniv Dary" <ydary(a)redhat.com>
Sent: Monday, June 22, 2015 4:16:26 PM
Subject: Fwd: Orphaning jasperreports
FYI
-------- Messaggio Inoltrato --------
Oggetto: Orphaning jasperreports
Data: Mon, 22 Jun 2015 14:56:55 +0200
Mittente: gil <puntogil(a)libero.it>
Rispondi-a: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>
A: Fedora Java Development List <java-devel(a)lists.fedoraproject.org>, Development discussions related to Fedora <devel(a)lists.fedoraproject.org>,
bigdata(a)lists.fedoraproject.org
HI
I have intention to orphaning/retire jasperreports [1] ,
because it fails build [2] with new batik (1.8)
and newer release use non free itext 5.x library.
[1] https://admin.fedoraproject.org/pkgdb/package/jasperreports/
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=10098415
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
9 years, 6 months
fyi - outage in jenkins.ovirt.org
by Eyal Edri
fyi,
there is currently an outage with jenkins.ovirt.org, seems related to an out of memory issue.
the infra team is investigating and will report when the issue is resolved.
you might experience some errors or infra issues with jenkins jobs running on patches,
if there is something urgent that can't wait for the fix, please let us know.
we hope the issue can be resolved within the next hour.
oVirt infra.
9 years, 6 months
Gluster patches on Alpha-1
by Christopher Pereira
This is a multi-part message in MIME format.
--------------030000060002050801070903
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sandro,
Can you please confirm this patches where released in alpha-1?
https://gerrit.ovirt.org/#/c/40239/
https://gerrit.ovirt.org/#/c/40240/
I just tested alpha-1 and vdsmd restart is still killing glusterd and
all VMs because it is running glusterd inside vdsmd's cgroup.
Can we please include them in alpha-2?
It's too dangerous to kill the storage because it corrupts VMs,
specially Windows ones.
Thanks.
--------------030000060002050801070903
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Sandro,<br>
<br>
Can you please confirm this patches where released in alpha-1?<br>
<blockquote><a class="moz-txt-link-freetext" href="https://gerrit.ovirt.org/#/c/40239/">https://gerrit.ovirt.org/#/c/40239/</a><br>
<a class="moz-txt-link-freetext" href="https://gerrit.ovirt.org/#/c/40240/">https://gerrit.ovirt.org/#/c/40240/</a><br>
</blockquote>
I just tested alpha-1 and vdsmd restart is still killing glusterd
and all VMs because it is running glusterd inside vdsmd's cgroup.<br>
<br>
Can we please include them in alpha-2?<br>
It's too dangerous to kill the storage because it corrupts VMs,
specially Windows ones.<br>
<br>
Thanks.<br>
</body>
</html>
--------------030000060002050801070903--
9 years, 6 months
