Re: [ovirt-devel] commons-collections v4.0
- Original Message -
From: Mike Kolesnik mkole...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: yzaspits yzasp...@redhat.com, devel@ovirt.org
Sent: Thursday, May 8, 2014 7:18:51 AM
Subject: Re: [ovirt-devel] commons-collections v4.0
- Original Message -
- Original Message -
From: Yevgeny Zaspitsky yzasp...@redhat.com
To: Alon Bar-Lev alo...@redhat.com, Mike Kolesnik
mkole...@redhat.com
Cc: devel@ovirt.org
Sent: Thursday, May 8, 2014 1:11:41 AM
Subject: Re: [ovirt-devel] commons-collections v4.0
On the other hand, changing a jar in the runtime environment without
compiling and running test with the new jar could lead an application to
stop functioning in a customer environment.
Also not every bug found in a dependency jar would cause a problem in the
application. (An application might not use the problematic part of the
dependency.)
I'd better trust the test suite (automatic and manual) that we run on the
compiled application with all the dependencies that the developers choose
at
the development time and then deliver that (with its dependencies as a
single package) to the customers.
Every bug in a dependency should be evaluated within the given
application
scope and only if proven as the given application problem only then the
application should be released.
So what you basically claim is that java developers and technology is not
mature enough to keep backward compatibility, so each java developer should
freeze a snapshot in time for his application to work.
I truly hope this is not the case.
There can always be regressions as you're well aware, and I don't know but
usually people who develop the libraries are not Einstein so yes, they do
break
backwards compatibility on occasions, sometimes even on purpose
(deprecation).
And for addressing your claim explicitly, what you can test at single point
in time, does not mean that it is definite as well, at customer site bugs
may be found also in the packages that you do test.
Well, when you test on site by dev qa you make sure you send something to
the
customer - X. When the dependencies are updated out of band, the customer
actually is using X'.
I can see at least 2 things wrong here:
1. You're putting the customer in a position of a tester for the X'
application.
2. If customer finds a bug he actually found it on X', whereas the developer
who
would be assigned to the bug could be using X'' by now.
If you're so keen on packaging a jar outside WAR file, we need to specify
explicit version and not =.
Explicit version is at if you pack it within your application, there is no
point in that.
Think of how RHEL is provided, think of Fedora, in all cases there are
components working together and each can be updated independently, and
amazingly - it works. You can think of Windows with all of its libraries and
interfaces (Microsoft or 3rd party), that application use, and it does work
without every [sane] application pulls the entire dependencies.
For some reason only people with Java background (including the J2EE designers)
assume that Java developers cannot be trusted for not breaking backward
compatibility in minor versions. This is not technical assumption but human
assumption, as there is no technical reason for Java library to break backward
compatibility within minor releases, so what does it tells us about what Java
developers thinks of them-selves?
Java will be ready for enterprise only when this is resolved. I hope all the
dependencies we are using are at the quality level that enables us to to trust
their developers.
Sent from Samsung Mobile
Original message
From: Alon Bar-Lev alo...@redhat.com
Date: 07/05/2014 21:41 (GMT+02:00)
To: Mike Kolesnik mkole...@redhat.com
Cc: Yevgeny Zaspitsky yzasp...@redhat.com,devel@ovirt.org
Subject: Re: [ovirt-devel] commons-collections v4.0
- Original Message -
From: Mike Kolesnik mkole...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Yevgeny Zaspitsky yzasp...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 9:34:03 PM
Subject: Re: [ovirt-devel] commons-collections v4.0
- Original Message -
- Original Message -
From: Yevgeny Zaspitsky yzasp...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: devel@ovirt.org
Sent: Tuesday, April 22, 2014 11:39:11 AM
Subject: Re: [ovirt-devel] commons-collections v4.0
That means that we manage 2 separate environments:
1. Development - relies on pom files. E.g. unit tests run with
commons-collections v3.1 (and when I add v4.0) and succeed.
devenv will use runtime option.
you are right about the unit tests, these relays on the poms.
I use devenv and it always uses the dev option not
Re: [ovirt-devel] Custom Properties code duplication
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 7:29:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 18:57, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 5:32:38 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 16:02, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org
Sent: Monday, May 5, 2014 7:08:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
Hey guys (and gals),
A few patches are up for review starting at:
http://gerrit.ovirt.org/#/c/27383
In total, about 250 lines of code removed, hopefully not at the cost of
regression. I put down some reviewers as I saw fit, but everyone can
feel free to add themselves. Summary of what was done compared to the
original plan:
1. Removed said dependencies, except for DeviceCustomPropertiesUtils
that was using the capture groups features of Pattern, and thus remained
in the utils project.
2. Done.
3. Done.
4. Almost didn't touch this, it seems to involve a lot of moving parts.
Yours, Lior.
On 30/04/14 18:01, Vojtech Szocs wrote:
Hi Lior, please find my comments inline.
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Lior Vernia lver...@redhat.com
Cc: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:28:06 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
- Original Message -
From: Lior Vernia lver...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:52:16 PM
Subject: [ovirt-devel] Custom Properties code duplication
Hello,
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.
+1
In general I am in favor, but how are you going to perform the regex
validation of values?
for example , with vm custom properties, you have - sap_agent that can
be
either true or false.
So you need to validate both at the client and the engine, right?
Lior mentioned above the possibility of using String methods, I assume
by this he means java.lang.String.matches(String) and similar methods.
During GWT compilation, JRE standard String implementation is replaced
by emulated (GWT-friendly) String implementation, which implements
methods like matches(String) using JavaScript RegExp object. You can
find this emulated implementation here:
gwt-user-{version}-sources.jar/com/google/gwt/emul/java/lang/String.java
Another alternative is to use GWT's built-in regex support through
com.google.gwt.regexp.shared.RegExp class. GWT's RegExp class has two
implementations, default one using JRE Pattern/Matcher, emulated one
using JavaScript RegExp object. The advantage is (mostly) consistent
regex support on both client and server, the disadvantage is server's
dependency on GWT JAR. (I don't think we want this.)
For simple regex matches, I'd suggest to simply go with String
approach.
For complex regex matches, we can use JRE Pattern/Matcher on server,
and emulate given implementation using GWT RegExp on client.
Note that there are (slight) differences between JRE's Pattern/Matcher
and JavaScript's RegExp object syntax/behavior. Check GWT RegExp class
Javadoc to see details (for simple cases, it's not a big deal, though).
2. Modify KeyValueModel to delegate to the common utilities instead
of
duplicating code, e.g. for validation.
+1
I see that KeyValueModel uses RegexValidation class that delegates to
compat's Regex class. Just like above, default Regex class utilizes
JRE Pattern/Matcher but client uses emuluated implementation:
gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Regex.java
and this emulated implementation uses GWT RegExp class.
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.
+1
4. Optionally change the implementation of custom properties
Re: [ovirt-devel] commons-collections v4.0
Am 07.05.2014 20:41, schrieb Alon Bar-Lev: Well, take the recent example of openssl issue that was found. Now, imagine that all products that use openssl should have been re-released. I think this is enough to understand how wrong this is. Exactly, if you want to take this serious, you must provide someone who monitors any upstream project you might include and especially backport security patches, maybe on your own, when talking about enterprise grade software. So any included hard dependency that will be shipped by ovirt must also be maintainable by ovirt. So it's always a good choice to have as little deps as possible but of course you always have _some_ . Where to draw the line is a very difficult task and should be very well reviewed. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Custom Properties code duplication
- Original Message -
From: Gilad Chaplik gchap...@redhat.com
To: Lior Vernia lver...@redhat.com
Cc: devel@ovirt.org
Sent: Thursday, May 8, 2014 9:50:19 AM
Subject: Re: [ovirt-devel] Custom Properties code duplication
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 7:29:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 18:57, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Gilad Chaplik gchap...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 5:32:38 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
On 07/05/14 16:02, Gilad Chaplik wrote:
- Original Message -
From: Lior Vernia lver...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org
Sent: Monday, May 5, 2014 7:08:23 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
Hey guys (and gals),
A few patches are up for review starting at:
http://gerrit.ovirt.org/#/c/27383
In total, about 250 lines of code removed, hopefully not at the cost
of
regression. I put down some reviewers as I saw fit, but everyone can
feel free to add themselves. Summary of what was done compared to the
original plan:
1. Removed said dependencies, except for DeviceCustomPropertiesUtils
that was using the capture groups features of Pattern, and thus
remained
in the utils project.
2. Done.
3. Done.
4. Almost didn't touch this, it seems to involve a lot of moving
parts.
Yours, Lior.
On 30/04/14 18:01, Vojtech Szocs wrote:
Hi Lior, please find my comments inline.
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Lior Vernia lver...@redhat.com
Cc: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:28:06 PM
Subject: Re: [ovirt-devel] Custom Properties code duplication
- Original Message -
From: Lior Vernia lver...@redhat.com
To: devel@ovirt.org
Sent: Wednesday, April 30, 2014 3:52:16 PM
Subject: [ovirt-devel] Custom Properties code duplication
Hello,
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.
+1
In general I am in favor, but how are you going to perform the regex
validation of values?
for example , with vm custom properties, you have - sap_agent that
can
be
either true or false.
So you need to validate both at the client and the engine, right?
Lior mentioned above the possibility of using String methods, I
assume
by this he means java.lang.String.matches(String) and similar
methods.
During GWT compilation, JRE standard String implementation is
replaced
by emulated (GWT-friendly) String implementation, which implements
methods like matches(String) using JavaScript RegExp object. You can
find this emulated implementation here:
gwt-user-{version}-sources.jar/com/google/gwt/emul/java/lang/String.java
Another alternative is to use GWT's built-in regex support through
com.google.gwt.regexp.shared.RegExp class. GWT's RegExp class has two
implementations, default one using JRE Pattern/Matcher, emulated one
using JavaScript RegExp object. The advantage is (mostly) consistent
regex support on both client and server, the disadvantage is server's
dependency on GWT JAR. (I don't think we want this.)
For simple regex matches, I'd suggest to simply go with String
approach.
For complex regex matches, we can use JRE Pattern/Matcher on server,
and emulate given implementation using GWT RegExp on client.
Note that there are (slight) differences between JRE's
Pattern/Matcher
and JavaScript's RegExp object syntax/behavior. Check GWT RegExp
class
Javadoc to see details (for simple cases, it's not a big deal,
though).
2. Modify KeyValueModel to delegate to the common utilities instead
of
duplicating code, e.g. for validation.
+1
I see that KeyValueModel uses RegexValidation class that delegates to
compat's Regex class. Just like above, default Regex class utilizes
JRE Pattern/Matcher but client uses emuluated implementation:
[ovirt-devel] oVirt 3.4.2 references
Hi, while we're performing last check on 3.4.1 repo before announcing it, here [1] you can find all the references for the pages related to 3.4.2 including: - Bug Tracker [2] - Release notes [3] - Testing results [4] Proposed timeline [5] is: - General availability: 2014-06-10 - RC Build: 2014-05-27 [1] http://www.ovirt.org/OVirt_3.4.z_release-management#oVirt_3.4.2 [2] http://bugzilla.redhat.com/1095370 [3] http://www.ovirt.org/OVirt_3.4.2_Release_Notes [4] http://www.ovirt.org/Testing/oVirt_3.4.2_Testing [5] http://www.ovirt.org/OVirt_3.4.z_release-management#Timeline Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] GFS2 mount via symlink problem
Hi, this issues i described on Red Hat bugzilla entry #888711 [1], but I'll recap here since there is come confusion (mostly my fault, sorry!) in the bug. System setup: CentOS 6.5 fully up to date SGI IS5000 SAS storage with 2 servers connected oVirt is 3.4.0 The Storage configured in oVirt is PosixFS, vfs type is gfs2 gfs2 is on top of CLVM Red Hat Cluster Manager (cman) is used to manage CLVM The issue is summarized by: [root@fionn-virt1 ~]# grep virtstorage /etc/fstab /dev/mapper/vg_is5000-lv_virtstorage/gfs2/virtstorage gfs2 noatime,nodiratime,nobarrier0 0 [root@fionn-virt1 ~]# grep virtstorage /proc/mounts /dev/dm-13 /gfs2/virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 /dev/dm-13 /rhev/data-center/mnt/_dev_mapper_vg__is5000-lv__virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 [root@fionn-virt1 ~]# grep virtstorage /etc/mtab /dev/mapper/vg_is5000-lv_virtstorage /gfs2/virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 /dev/mapper/vg_is5000-lv_virtstorage /rhev/data-center/mnt/_dev_mapper_vg__is5000-lv__virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 The storage is mounted twice, first by the gfs2 init script and then by ovirt. As you can see even if both ovirt and gfs2 init script used the /dev/mapper/name symlink, in proc mounts there is the real device specified, the one the symlink is pointing to. I have no clue why only GFS2 does that (at least ext* FS are not, didn't checked anything else TBO, I have only ext* FS on other LVM volumes on the same system). In this case oVirt fails to check if the FS is mounted, since there is no entry in /proc/mounts matching the device name specified (the /dev/mapper/name one). I my example above I already applied a fix for that, so it is actually working. I've submitted a fix to ovirt gerrit, see [2], [3] and [4] (the latter is a unit test for checking gfs2). Note that [2] alone is not correct, it needs [3] as well to not break some other setup. Dan Kenigsberg of Red Hat suggested to move the discussion here, since this is a weird issue (why just GFS2 resolves the symlink?). I'm looking for advise, comments to the fix I proposed, but also about if this is actually the better fix? Like fixing GFS2 in the first place. That said I still think this should be handled by ovirt. It doesn't really matter if in /proc/mounts you have the symlink or the real device, it is the same mount Kind regards Enrico [1] https://bugzilla.redhat.com/show_bug.cgi?id=888711 [2] http://gerrit.ovirt.org/27321 [3] http://gerrit.ovirt.org/27425 [4] http://gerrit.ovirt.org/27514 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Vdsm patches need review and merge
- Original Message - From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com To: Dan Kenigsberg (dan...@redhat.com) dan...@redhat.com, Francesco Romani from...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com (gchap...@redhat.com) gchap...@redhat.com, Doron Fediuck (dfedi...@redhat.com) dfedi...@redhat.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, devel@ovirt.org, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com Sent: Thursday, May 8, 2014 2:33:14 PM Subject: RE: Vdsm patches need review and merge Hi Dan/Francesco, Could you help to review and merge these patches: http://gerrit.ovirt.org/#/c/27515/ (This patch is needed by 26876 since some comments in that patch need to modify caps module) http://gerrit.ovirt.org/#/c/26876/ http://gerrit.ovirt.org/#/c/27403/ I didn't modify some comments in 26876 since I think they are related with codes refactor and literal syntax. I will submit a separate patch to modify these kinds of comments of numa feature altogether later. Could you please now focus on the functionality since we need to merge these patches ASAP? http://gerrit.ovirt.org/#/c/27403 I'm OK with it (gave +1) http://gerrit.ovirt.org/#/c/26876 I don't have objections and I don't see blockers for the functionality. I'm not 100% happy with the implementation, but the existing one is on par with most of code, and if we're in hurry, I guess refinements can wait. http://gerrit.ovirt.org/#/c/27515 good enough for the same reasons above (gave +1) Bests, -- Francesco Romani RedHat Engineering Virtualization R D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ANN] oVirt 3.4.1 Release is now available
The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org Sent: Thursday, May 8, 2014 4:02:52 PM Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ What is plain? Sources are not available, example[1] [1] http://resources.ovirt.org/pub/src/ovirt-engine/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
plain is, when you don't use this fancy webgui for displaying the folders, I forgot the name.. Am 08.05.2014 15:51, schrieb Alon Bar-Lev: What is plain? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
Il 08/05/2014 16:00, Sandro Bonazzola ha scritto: Il 08/05/2014 15:51, Alon Bar-Lev ha scritto: - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org Sent: Thursday, May 8, 2014 4:02:52 PM Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ What is plain? Sorry, my bad in copy / paste from firefox. it just disable the theme, both with and without /plain/ points to the same files. Sources are not available, example[1] [1] http://resources.ovirt.org/pub/src/ovirt-engine/ Sure, sources are available in http://resources.ovirt.org/pub/src/ and on http://gerrit.ovirt.org I'll remember to add the links to the next announce. Correcting myself, for some reason sources are in http://resources.ovirt.org/pub/ovirt-3.4/src/ and not in http://resources.ovirt.org/pub/src/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Vdsm patches need review and merge
On Thu, May 08, 2014 at 08:48:52AM -0400, Francesco Romani wrote: - Original Message - From: Xiao-Lei Shi (Bruce, HP Servers-PSC-CQ) xiao-lei@hp.com To: Dan Kenigsberg (dan...@redhat.com) dan...@redhat.com, Francesco Romani from...@redhat.com Cc: Gilad Chaplik gchap...@redhat.com (gchap...@redhat.com) gchap...@redhat.com, Doron Fediuck (dfedi...@redhat.com) dfedi...@redhat.com, Chuan Liao (Jason Liao, HPservers-Core-OE-PSC) chuan.l...@hp.com, devel@ovirt.org, Shang-Chun Liang (David Liang, HPservers-Core-OE-PSC) shangchun.li...@hp.com Sent: Thursday, May 8, 2014 2:33:14 PM Subject: RE: Vdsm patches need review and merge Hi Dan/Francesco, Could you help to review and merge these patches: http://gerrit.ovirt.org/#/c/27515/ (This patch is needed by 26876 since some comments in that patch need to modify caps module) http://gerrit.ovirt.org/#/c/26876/ http://gerrit.ovirt.org/#/c/27403/ I didn't modify some comments in 26876 since I think they are related with codes refactor and literal syntax. I will submit a separate patch to modify these kinds of comments of numa feature altogether later. Could you please now focus on the functionality since we need to merge these patches ASAP? http://gerrit.ovirt.org/#/c/27403 I'm OK with it (gave +1) http://gerrit.ovirt.org/#/c/26876 I don't have objections and I don't see blockers for the functionality. I'm not 100% happy with the implementation, but the existing one is on par with most of code, and if we're in hurry, I guess refinements can wait. http://gerrit.ovirt.org/#/c/27515 good enough for the same reasons above (gave +1) Puritans would suggest to squash this into 26876, or fix the commit message - prior to 26876 nothing uses these private methods. But never mind, taken. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
On Thu 08 May 2014 04:02:04 PM CEST, Sandro Bonazzola wrote: Il 08/05/2014 16:00, Sandro Bonazzola ha scritto: Il 08/05/2014 15:51, Alon Bar-Lev ha scritto: - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org Sent: Thursday, May 8, 2014 4:02:52 PM Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ What is plain? Sorry, my bad in copy / paste from firefox. it just disable the theme, both with and without /plain/ points to the same files. Sources are not available, example[1] [1] http://resources.ovirt.org/pub/src/ovirt-engine/ Sure, sources are available in http://resources.ovirt.org/pub/src/ and on http://gerrit.ovirt.org I'll remember to add the links to the next announce. Correcting myself, for some reason sources are in http://resources.ovirt.org/pub/ovirt-3.4/src/ and not in http://resources.ovirt.org/pub/src/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users I can help with that, should I move or copy the sources? -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
Il 08/05/2014 16:27, David Caro ha scritto: On Thu 08 May 2014 04:02:04 PM CEST, Sandro Bonazzola wrote: Il 08/05/2014 16:00, Sandro Bonazzola ha scritto: Il 08/05/2014 15:51, Alon Bar-Lev ha scritto: - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org Sent: Thursday, May 8, 2014 4:02:52 PM Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ What is plain? Sorry, my bad in copy / paste from firefox. it just disable the theme, both with and without /plain/ points to the same files. Sources are not available, example[1] [1] http://resources.ovirt.org/pub/src/ovirt-engine/ Sure, sources are available in http://resources.ovirt.org/pub/src/ and on http://gerrit.ovirt.org I'll remember to add the links to the next announce. Correcting myself, for some reason sources are in http://resources.ovirt.org/pub/ovirt-3.4/src/ and not in http://resources.ovirt.org/pub/src/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users I can help with that, should I move or copy the sources? I think move is better, let's avoid confusion in src location. -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
Il 08/05/2014 15:51, Alon Bar-Lev ha scritto: - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org Sent: Thursday, May 8, 2014 4:02:52 PM Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ What is plain? Sorry, my bad in copy / paste from firefox. it just disable the theme, both with and without /plain/ points to the same files. Sources are not available, example[1] [1] http://resources.ovirt.org/pub/src/ovirt-engine/ Sure, sources are available in http://resources.ovirt.org/pub/src/ and on http://gerrit.ovirt.org I'll remember to add the links to the next announce. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: David Caro dcaro...@redhat.com Cc: devel@ovirt.org, Alon Bar-Lev alo...@redhat.com Sent: Thursday, May 8, 2014 5:44:43 PM Subject: Re: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available Il 08/05/2014 16:27, David Caro ha scritto: On Thu 08 May 2014 04:02:04 PM CEST, Sandro Bonazzola wrote: Il 08/05/2014 16:00, Sandro Bonazzola ha scritto: Il 08/05/2014 15:51, Alon Bar-Lev ha scritto: - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org Sent: Thursday, May 8, 2014 4:02:52 PM Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ What is plain? Sorry, my bad in copy / paste from firefox. it just disable the theme, both with and without /plain/ points to the same files. Sources are not available, example[1] [1] http://resources.ovirt.org/pub/src/ovirt-engine/ Sure, sources are available in http://resources.ovirt.org/pub/src/ and on http://gerrit.ovirt.org I'll remember to add the links to the next announce. Correcting myself, for some reason sources are in http://resources.ovirt.org/pub/ovirt-3.4/src/ and not in http://resources.ovirt.org/pub/src/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list us...@ovirt.org http://lists.ovirt.org/mailman/listinfo/users I can help with that, should I move or copy the sources? I think move is better, let's avoid confusion in src location. I do not care if there are sources at 3.4, but must be at /pub/src, still waiting for releasing ebuilds. -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
