I would like to propose Yedidyah Bar David as oVirt Hosted Engine Setup co-maintainer.
Yedidyah contributed to oVirt Hosted Engine Setup since early design phase and contributed dozens of patches.
Your response would be appreciated.
Thanks in advance.
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
While adding network custom properties towards oVirt 3.5, I got to take
a good look at the custom properties code in the backend and frontend.
It seems to me like there's a lot of code duplication, and I would like
to suggest the following refactoring:
1. Remove dependencies on Pattern/Matcher and ApacheCommons methods from
*CustomPropertiesUtils.java, to make them compilable with GWT, and move
these utilities to the common package. The usage of the said methods is
minimal and could easily be replaced with String methods, etc.
2. Modify KeyValueModel to delegate to the common utilities instead of
duplicating code, e.g. for validation.
3. Move some validation, which is relevant to all custom properties
(e.g. duplicate keys), from specific utils (e.g. VmPropertiesUtils) up
to the shared CustomPropertiesUtils.
4. Optionally change the implementation of custom properties members in
entities (e.g. VM) from String to Map<String, String>, which would
obviate the need for different conversion methods between String/Map -
(de)serialization would only be required in DB interaction.
The main argument against this would be that the frontend is to be moved
over the REST, and might not be written in Java much longer anyway.
However, to my understanding, there's some time until these changes take
least initially the existing frontend code will have to still be used
refactoring might still be beneficial for the not-so-short term.
Before going through with this, I wanted to ask for your thoughts and to
hear any specific objections to the proposed changes.
I'd like to add the new version (4.0) of Apache commons-collections library to the dependencies of the project (we use 3.1 currently).
The new version uses the generics features of Java 5 so that make the code more type safe. You can find the full list of changes on https://commons.apache.org/proper/commons-collections/release_4_0.html.
The new API is based on the original but it isn't fully compatible with it. So in order to make the migration to the new API easier, the package has been changed to org.apache.commons.collections4. That allows having both version of the library in the classpath at the starting point and move (refactor) towards the new version gradually.
I have couple of questions regarding the new dependency:
1. Is there anything that could prevent adding the new dependency?
2. I did the change (http://gerrit.ovirt.org/26745).
The unit tests that use the new dependency pass locally and in Jenkins environments.
However when I try to run a code that is dependent on the newly added library NoClassDefFoundError being thrown.
Also I can't find commons-collections4 jar under the installation directory. I use "make clean install-dev" command for building.
Senior Software Engineer
---------- Forwarded message ----------
From: "Andrew Lutomirski" <luto(a)mit.edu>
Date: Apr 30, 2014 7:46 PM
Subject: Re: Mass bug: packages should not auto-enable systemd units
Due to some confusion around how alternatives worked, I screwed up the
list of packages here. I've updated it below. I'll give it a few
more days before filing the actual bugs.
On Wed, Apr 23, 2014 at 4:59 PM, Andrew Lutomirski <luto(a)mit.edu> wrote:
> Hi everyone-
> This is a notice in accordance with the mass bug filing procedure.
> A number of packages install systemd units and enable them
> automatically. They should not. Please update these packages to use the
> macroized scriptlet
> If your package has an exception from FESCo permitting it to enable
> itself, please make sure that the service in question is listed in the
> appropriate preset file.
> There is a general exception described here:
> If your package falls under the general exception, then it is possible
> that no change is required. Nevertheless, if you are relying on the
> exception, please make sure that your rpm scripts are sensible. The
> exception is:
> In addition, any service which does not remain persistent on the
> system (aka, it "runs once then goes away"), does not listen to
> incoming connections during initialization, and does not require
> configuration to be functional may be enabled by default (but is not
> required to do so). An example of "runs once then goes away" service
> is iptables.
> Given that this issue can affect Fedora 20 users who install your
> package as a dependency, these bugs should be fixed in Fedora 20 and
> The tracker bug is here:
> I created it early because three of the bugs are pre-existing. Next
> week, I'll file bugs against the packages below. If you fix your
> package in the mean time, please let me know.
> After three weeks, provenpackagers may step in and fix these issues.
devel-announce mailing list
somehow we missed the summary of this call, and few "big" issues were
raised there. so i would like to share it with all and hear more comments
- task id in http header - allows engine to initiate calls with id
instead of following vdsm response - federico already started this work,
and this is mandatory for live merge feature afaiu.
- fromani: Suggested thread pool for libvirt-related operations. if this
can be elaborated more, please do. i don't recall the details or other
- danken: we should press on with the patches that keep VMs in Down
state: removing them on vdsm restart keeps lvs in activated state which
may spell trouble
- splitting vdsm infra\generic code to sub-vdsm-module instead of
creating separate packages. This can be done by splitting the git
repository to allow "easy" maintenance of the code (from infra
prospective) which includes also C parts and generic tools that can be
used in other projects as well.
if i missed anything, please add
The "memory.used" statistic on a virtual machine is returning a negative
value , ie.
by the RHEVM 3.2 ReST API.
while, in the Web Administration Console, memory consumption for the same
VM, shows a positive percentage value.
Is this an issue with the ReST API?