- Devel - oVirt List Archives

Very slow push/pull to/from gerrit
by Nir Soffer 23 Sep '20

23 Sep '20

Recently pushing changes to gerrit is very slow. It seems that the issue is pulling changes during rebase in "git review". Sometimes "git review" is very slow, but "git review -R" is very quick. This show that the issue was getting changes from gerrit during when git-review try to rebase the current branch on master. I noticed that origin/master and gerrit/master do not show the same commit: $ git log origin/master | head -1 commit 6e6e93cb1d237f9b6fdd533d5afdc1b9ba1c197a $ git log gerrit/master | head -1 commit 353e7b1e322aa02d4767b6617ed094be0643b094 $ git remote -v gerrit http://gerrit.ovirt.org/p/vdsm.git (fetch) gerrit ssh://nsoffer@gerrit.ovirt.org:29418/vdsm.git (push) origin http://gerrit.ovirt.org/p/vdsm.git (fetch) origin http://gerrit.ovirt.org/p/vdsm.git (push) I've been using this configuration for several years, and the slowness started only recently, so I guess the issue is not on my side. Same issues also on ovirt-engine, using similar configuration: $ git remote -v gerrit http://gerrit.ovirt.org/ovirt-engine (fetch) gerrit ssh://nsoffer@gerrit.ovirt.org:29418/ovirt-engine.git (push) origin git://gerrit.ovirt.org/ovirt-engine (fetch) origin git://gerrit.ovirt.org/ovirt-engine (push) Anyone experienced this? I guess that restarting the gerrit server will "fix" this issue. Nir

1 1

Possible i18n for cockpit-ovirt ?
by Juliette Tux 23 Sep '20

23 Sep '20

Hello, Localizator/translator here :) I have a small question regarding the cockpit-ovirt utility[1]. Are there any plans of adding the i18n into the code to facilitate proper translation of cockpit-ovirt? Thank you! [1] https://resources.ovirt.org/pub/ovirt-4.3/src/cockpit-ovirt/ -- С уважением, Дронова Юлия

3 5

ovirt-engine has been tagged (ovirt-engine-4.4.3.4)
by Tal Nisan 22 Sep '20

22 Sep '20

1 0

ioprocess 1.4.2 not tagged
by Sandro Bonazzola 21 Sep '20

21 Sep '20

Hi, last commit on ioprocess says: * ae379c8 - (HEAD -> master, origin/master, origin/HEAD) release: Bump version to 1.4.2 (12 giorni fa) <Eyal Shenitzky> But it's missing a tag and it has not been added to releng-tools for being included in oVirt 4.4.3 release candidate. Anything missing there or can we release it? Thanks, -- 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.*

2 3

ovirt-engine-api-model master fail to build on Fedora 32 (Fatal error compiling: invalid flag: --release)
by Nir Soffer 21 Sep '20

21 Sep '20

I'm trying to build master on Fedora 32. This worked last week with: commit cbb664f1b5b87e05fec535461cfa09c758b033c2 (gerrit/master) Author: Martin Perina <mperina(a)redhat.com> Date: Mon Sep 14 12:49:33 2020 +0200 Make check-patch.packages a link to build-artifacts.packages But is broken now with: commit e821632e04626f72957177e49f03ca90bcbb5b77 (HEAD -> master, origin/master, origin/HEAD) Author: Ori_Liel <oliel(a)redhat.com> Date: Sat Sep 19 13:18:55 2020 +0300 [maven-release-plugin] prepare for next development iteration Here is example build: $ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ---------------------< org.ovirt.engine.api:model >--------------------- [INFO] Building oVirt API Model 4.4.19-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ model --- [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.8.0: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 [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.694 s [INFO] Finished at: 2020-09-21T12:50:16+03:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project model: Fatal error compiling: invalid flag: --release -> [Help 1] Do we have any way to fix this? Nir

2 2

Bug 1880171 - Upgrading host (or checking for updates) fails after 4.4.2 ovirt-engine upgrade
by Sandro Bonazzola 21 Sep '20

21 Sep '20

Hi, I'd like to propose to go with async fix for *Bug 1880171* <https://bugzilla.redhat.com/show_bug.cgi?id=1880171> - Upgrading host (or checking for updates) fails after 4.4.2 ovirt-engine upgrade and release it async for 4.4.2 as soon as possible. If you agree, I'll add ovirt-4.4.2-1 target milestone to oVirt classification. Thanks, -- 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.*

1 0

Error building ovirt-engine-api-model on Fedora 32
by Nir Soffer 17 Sep '20

17 Sep '20

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 8

Removal of deprecated init-scripts (network-scripts)
by Ales Musil 16 Sep '20

16 Sep '20

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>

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.3.3)
by Tal Nisan 15 Sep '20

15 Sep '20

1 0

device compatibility interface for live migration with assigned devices
by Yan Zhao 15 Sep '20

15 Sep '20

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/libvi… Thanks Yan

14 117