Error building ovirt-engine-api-model on Fedora 32
by Nir Soffer
I'm trying to build with this change:
https://gerrit.ovirt.org/c/111312/
And it fails to build. Same error on master
(commit 2e3c836e4c2fd50258e96bc6966b5d9680b5332e).
Anyone has a clue what is the reason for this? any workaround?
$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] ---------------------< org.ovirt.engine.api:model >---------------------
[INFO] Building oVirt API Model 4.4.18-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ model ---
[INFO] Deleting /home/nsoffer/src/ovirt-engine-api-model/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ model ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/nsoffer/src/ovirt-engine-api-model/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ model ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 601 source files to
/home/nsoffer/src/ovirt-engine-api-model/target/classes
[WARNING] /home/nsoffer/src/ovirt-engine-api-model/src/main/java/services/DisksService.java:
Some input files use or override a deprecated API.
[WARNING] /home/nsoffer/src/ovirt-engine-api-model/src/main/java/services/DisksService.java:
Recompile with -Xlint:deprecation for details.
[INFO]
[INFO] --- exec-maven-plugin:1.4.0:java (generate-doc) @ model ---
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/home/nsoffer/.m2/repository/org/slf4j/slf4j-log4j12/1.7.7/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/nsoffer/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.jboss.classfilewriter.ClassFile$1
(file:/home/nsoffer/.m2/repository/org/jboss/weld/se/weld-se/2.3.0.Final/weld-se-2.3.0.Final.jar)
to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Please consider reporting this to the maintainers of
org.jboss.classfilewriter.ClassFile$1
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
ERROR org.ovirt.api.metamodel.tool.Main - Error while executing the
"run" method of tool class "org.ovirt.api.metamodel.tool.Tool".
java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.ovirt.api.metamodel.tool.Main.main(Main.java:74)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049:
Unable to invoke public void
org.ovirt.api.metamodel.tool.AsciiDocHtmlGenerator.init() on
org.ovirt.api.metamodel.tool.AsciiDocHtmlGenerator@6ef4091
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81)
at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:171)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72)
at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
at org.ovirt.api.metamodel.tool.XmlDescriptionGenerator$Proxy$_$$_WeldClientProxy.generate(Unknown
Source)
at org.ovirt.api.metamodel.tool.Tool.run(Tool.java:383)
at org.ovirt.api.metamodel.tool.Tool$Proxy$_$$_WeldClientProxy.run(Unknown
Source)
... 11 more
Caused by: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98)
... 36 more
Caused by: java.lang.ExceptionInInitializerError
at org.asciidoctor.internal.JRubyAsciidoctor.createOptimizedConfiguration(JRubyAsciidoctor.java:151)
at org.asciidoctor.internal.JRubyAsciidoctor.createJRubyAsciidoctorInstance(JRubyAsciidoctor.java:114)
at org.asciidoctor.internal.JRubyAsciidoctor.create(JRubyAsciidoctor.java:62)
at org.asciidoctor.Asciidoctor$Factory.create(Asciidoctor.java:647)
at org.ovirt.api.metamodel.tool.AsciiDocHtmlGenerator.init(AsciiDocHtmlGenerator.java:39)
... 41 more
Caused by: java.lang.RuntimeException: unsupported Java version: 11
at org.jruby.RubyInstanceConfig.initGlobalJavaVersion(RubyInstanceConfig.java:1858)
at org.jruby.RubyInstanceConfig.<clinit>(RubyInstanceConfig.java:1608)
... 46 more
Weld SE container STATIC_INSTANCE shut down by shutdown hook
3 years, 7 months
Removal of deprecated init-scripts (network-scripts)
by Ales Musil
Hello,
network-scripts for host networking were deprecated since oVirt 4.4.
It will be removed completely in the 4.4.3 release. There is no action
required
for setups that did not change the configuration to use network-scripts
backend (net_nmstate_enabled = false).
Users that did disable nmstate should redeploy all affected hosts before
4.4.3.
Also can you please tell us what was the reason to use network-scripts, if
that is the case?
Thank you.
Best regards,
Ales Musil
--
Ales Musil
Software Engineer - RHV Network
Red Hat EMEA <https://www.redhat.com>
amusil(a)redhat.com IM: amusil
<https://red.ht/sig>
3 years, 7 months
device compatibility interface for live migration with assigned devices
by Yan Zhao
hi folks,
we are defining a device migration compatibility interface that helps upper
layer stack like openstack/ovirt/libvirt to check if two devices are
live migration compatible.
The "devices" here could be MDEVs, physical devices, or hybrid of the two.
e.g. we could use it to check whether
- a src MDEV can migrate to a target MDEV,
- a src VF in SRIOV can migrate to a target VF in SRIOV,
- a src MDEV can migration to a target VF in SRIOV.
(e.g. SIOV/SRIOV backward compatibility case)
The upper layer stack could use this interface as the last step to check
if one device is able to migrate to another device before triggering a real
live migration procedure.
we are not sure if this interface is of value or help to you. please don't
hesitate to drop your valuable comments.
(1) interface definition
The interface is defined in below way:
__ userspace
/\ \
/ \write
/ read \
________/__________ ___\|/_____________
| migration_version | | migration_version |-->check migration
--------------------- --------------------- compatibility
device A device B
a device attribute named migration_version is defined under each device's
sysfs node. e.g. (/sys/bus/pci/devices/0000\:00\:02.0/$mdev_UUID/migration_version).
userspace tools read the migration_version as a string from the source device,
and write it to the migration_version sysfs attribute in the target device.
The userspace should treat ANY of below conditions as two devices not compatible:
- any one of the two devices does not have a migration_version attribute
- error when reading from migration_version attribute of one device
- error when writing migration_version string of one device to
migration_version attribute of the other device
The string read from migration_version attribute is defined by device vendor
driver and is completely opaque to the userspace.
for a Intel vGPU, string format can be defined like
"parent device PCI ID" + "version of gvt driver" + "mdev type" + "aggregator count".
for an NVMe VF connecting to a remote storage. it could be
"PCI ID" + "driver version" + "configured remote storage URL"
for a QAT VF, it may be
"PCI ID" + "driver version" + "supported encryption set".
(to avoid namespace confliction from each vendor, we may prefix a driver name to
each migration_version string. e.g. i915-v1-8086-591d-i915-GVTg_V5_8-1)
(2) backgrounds
The reason we hope the migration_version string is opaque to the userspace
is that it is hard to generalize standard comparing fields and comparing
methods for different devices from different vendors.
Though userspace now could still do a simple string compare to check if
two devices are compatible, and result should also be right, it's still
too limited as it excludes the possible candidate whose migration_version
string fails to be equal.
e.g. an MDEV with mdev_type_1, aggregator count 3 is probably compatible
with another MDEV with mdev_type_3, aggregator count 1, even their
migration_version strings are not equal.
(assumed mdev_type_3 is of 3 times equal resources of mdev_type_1).
besides that, driver version + configured resources are all elements demanding
to take into account.
So, we hope leaving the freedom to vendor driver and let it make the final decision
in a simple reading from source side and writing for test in the target side way.
we then think the device compatibility issues for live migration with assigned
devices can be divided into two steps:
a. management tools filter out possible migration target devices.
Tags could be created according to info from product specification.
we think openstack/ovirt may have vendor proprietary components to create
those customized tags for each product from each vendor.
e.g.
for Intel vGPU, with a vGPU(a MDEV device) in source side, the tags to
search target vGPU are like:
a tag for compatible parent PCI IDs,
a tag for a range of gvt driver versions,
a tag for a range of mdev type + aggregator count
for NVMe VF, the tags to search target VF may be like:
a tag for compatible PCI IDs,
a tag for a range of driver versions,
a tag for URL of configured remote storage.
b. with the output from step a, openstack/ovirt/libvirt could use our proposed
device migration compatibility interface to make sure the two devices are
indeed live migration compatible before launching the real live migration
process to start stream copying, src device stopping and target device
resuming.
It is supposed that this step would not bring any performance penalty as
-in kernel it's just a simple string decoding and comparing
-in openstack/ovirt, it could be done by extending current function
check_can_live_migrate_destination, along side claiming target resources.[1]
[1] https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/lib...
Thanks
Yan
3 years, 7 months
Re: oVirt Terraform Provider
by Sandro Bonazzola
Il giorno gio 3 set 2020 alle ore 12:29 Jake Reynolds <
jake.reynolds(a)bidfx.com> ha scritto:
> Hi,
>
> A number of PRs (bug fixes & feature additions) are outstanding on the
> oVirt Terraform Provider https://github.com/oVirt/terraform-provider-ovirt.
> There seems to have been no activity on the master branch of the repo for
> months.
>
> 1. How can I promote/request that PRs are reviewed in a timely manner?
>
> Hi,
+Roy Golan <rgolan(a)redhat.com> , +Roberto Ciatti <rciatti(a)redhat.com> , +Gal
Zaidman <gzaidman(a)redhat.com> , +Evgeny Slutsky <eslutsky(a)redhat.com> can
you please review pull requests in
https://github.com/oVirt/terraform-provider-ovirt/pulls ?
Thanks,
>
> 1.
> 2. I am using this to deploy a global infrastructure over the next
> year and expect to be doing further extensions/improvements over that time
> (done 5 PRs in the past few weeks alone). How do I go about becoming part
> of the community and getting write access to this repo if there is no
> active maintainer?
>
>
Welcome aboard :-) you're now part of the community!
For getting merge rights into the repo, current maintainer should accept
you as co-maintainer there.
You can discuss here further extensions/improvements you'd like to work on
or open bugs/rfe on
https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-distribution&comp...
for starting the discussion.
If you prefer to work on github only I would recommend to ping here as
well, to be sure people will be aware of the issue / pull request has been
opened.
>
> 1.
>
> Thanks,
>
>
> Jake
>
>
> _______________________________________________
> Devel mailing list -- devel(a)ovirt.org
> To unsubscribe send an email to devel-leave(a)ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/QCECG5CP4XO...
>
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
3 years, 7 months
[ARM64] Possiblity to support oVirt on ARM64
by Zhenyu Zheng
Hi oVirt,
We are currently trying to make oVirt work on ARM64 platform, since I'm
quite new to oVirt community, I'm wondering what is the current status
about ARM64 support in the oVirt upstream, as I saw the oVirt Wikipedia
page mentioned there is an ongoing efforts to support ARM platform. We have
a small team here and we are willing to also help to make this work.
Thanks alot,
Zhenyu Zheng
3 years, 7 months
