performance improvements and gwt-rpc switch
Hi everyone, For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin performance improvements. There have been some reports [1] [2] of UI sluggishness in both 3.6 and 4.0, usually after the browser had been open some time, and usually in scale environments. After some research, we determined that the primary cause of this sluggishness was memory leaks. We embarked on several weeks of hunting down memory leak bugs and squashing them. Alexander Wels and Vojtech Szocs led this work, and I helped test the performance of each patch as they created them. As they created patches to squash leaks, performance kept getting better and better. Today we've merged the last of our patches [*], and I'm happy to announce that we are now seeing much better UI performance on 4.1-master and 4.0.6. Over the course of several hours with the browser window open, users should see no sluggishness at all. [*] This last patch switches oVirt from using de-rpc to gwt-rpc in the frontend. This improves performance, but it also allows us to upgrade to GWT 2.8. We'd been previously blocked on that. If you're interested in UI performance testing, continue reading. If not, you can stop here :) ..... To verify our performance improvements, we took some simple measurements using selenium webdriver. The tests were unscientific, but very helpful. We ran a webdriver flow through oVirt that clicked some buttons and tabs and refreshed some grids. We did it a few hundred or thousand times. The tests were run using stubbed hosts (ovirt-vdsmfake) so that only the engine and UI were under test. Below are the important takeaways. The x axis is time, and each point on a graph is a loop through the same webdriver flow. The (ms) y axes are response times, and memory is in MB. In this graph, we compare oVirt 4.1 with and without our most impactful patch applied. As you can see, with the patch applied, response time stays flat for 200 loops of my test script over the course of 18 and 43 minutes. Without the patch applied, response time quickly degraded such that 200 loops of my test script took 1 hr 2 minutes vs. 18 minutes with the patch applied -- a 66% improvement! [image: Inline image 1] In this graph [ignore the spike], we tested oVirt hard for 6 hours 25 minutes (2000 loops). As you can see, the response times stay relatively flat over 6 hours! This is a great improvement. Do note that the memory is still growing, albeit much more slowly now. You can see towards the end of this run, maybe around hour 5, that the deviation starts to go up (the line thickens). Takeaway: maybe refresh your browser after many hours of having webadmin open. But, this is a stress test -- I'm betting users won't notice this slowdown after even 6 hours of regular webadmin use or idling. Last, here is a graph that shows gwt-rpc performing slightly better than de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster rpc implementation. Reply with any questions or concerns. Thanks! Best wishes, Greg [1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462 -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
On Mon, Nov 28, 2016 at 8:43 PM, Greg Sheremeta <gshereme@redhat.com> wrote:
Hi everyone,
For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin performance improvements. There have been some reports [1] [2] of UI sluggishness in both 3.6 and 4.0, usually after the browser had been open some time, and usually in scale environments.
After some research, we determined that the primary cause of this sluggishness was memory leaks.
We embarked on several weeks of hunting down memory leak bugs and squashing them. Alexander Wels and Vojtech Szocs led this work, and I helped test the performance of each patch as they created them. As they created patches to squash leaks, performance kept getting better and better. Today we've merged the last of our patches [*], and I'm happy to announce that we are now seeing much better UI performance on 4.1-master and 4.0.6.
Over the course of several hours with the browser window open, users should see no sluggishness at all.
[*] This last patch switches oVirt from using de-rpc to gwt-rpc in the frontend. This improves performance, but it also allows us to upgrade to GWT 2.8. We'd been previously blocked on that.
If you're interested in UI performance testing, continue reading. If not, you can stop here :)
.....
To verify our performance improvements, we took some simple measurements using selenium webdriver. The tests were unscientific, but very helpful. We ran a webdriver flow through oVirt that clicked some buttons and tabs and refreshed some grids. We did it a few hundred or thousand times. The tests were run using stubbed hosts (ovirt-vdsmfake) so that only the engine and UI were under test.
Below are the important takeaways. The x axis is time, and each point on a graph is a loop through the same webdriver flow. The (ms) y axes are response times, and memory is in MB.
In this graph, we compare oVirt 4.1 with and without our most impactful patch applied. As you can see, with the patch applied, response time stays flat for 200 loops of my test script over the course of 18 and 43 minutes. Without the patch applied, response time quickly degraded such that 200 loops of my test script took 1 hr 2 minutes vs. 18 minutes with the patch applied -- a 66% improvement! [image: Inline image 1] In this graph [ignore the spike], we tested oVirt hard for 6 hours 25 minutes (2000 loops). As you can see, the response times stay relatively flat over 6 hours! This is a great improvement. Do note that the memory is still growing, albeit much more slowly now. You can see towards the end of this run, maybe around hour 5, that the deviation starts to go up (the line thickens). Takeaway: maybe refresh your browser after many hours of having webadmin open. But, this is a stress test -- I'm betting users won't notice this slowdown after even 6 hours of regular webadmin use or idling.
Last, here is a graph that shows gwt-rpc performing slightly better than de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster rpc implementation.
I'm wondering if we have any data about de-rpc vs. gwt-rpc under WAN conditions. With latency (say, 70ms, based on [1]) and possibly some packet loss (0.5% should suffice). Y. [1] http://www.internettrafficreport.com/30day.htm
Reply with any questions or concerns. Thanks!
Best wishes, Greg
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Tue, Nov 29, 2016 at 4:40 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
is a graph that shows gwt-rpc performing slightly better than de-rpc.
Memory consumption is about the same -- gwt-rpc is just a faster rpc implementation.
I'm wondering if we have any data about de-rpc vs. gwt-rpc under WAN conditions. With latency (say, 70ms, based on [1]) and possibly some packet loss (0.5% should suffice). Y.
We did WAN testing for the memory leaks, but not for the rpc change. (The ask got misinterpreted by me -- my bad.) I'll get you some results for this this week. Greg
Thanks Greg for the excellent write-up! oVirt WebAdmin UI is quite complex, with lots of abstractions (the GWT technology being a Java-on-top-of-Web-APIs abstraction itself) as well as many features (and lots of dialogs..) so this task wasn't easy, but I guess we managed to get UI into a stabilized state now. Dialogs (non-singleton by design) were a major source of memory leaks, so we added UI infra to ensure automatic dialog cleanup. In 4.2, we'd like to upgrade GWT SDK version to latest stable (2.8.x) which will hopefully improve GWT compiler performance and, importantly, allow us to use Java 8 language features in our GWT UI code. There's still potential for improvement, we're tracking that through: [tracker] oVirt UI performance improvements https://bugzilla.redhat.com/1378935 (some IE-specific improvements are already submitted as part of ^^) Regards, Vojtech ----- Original Message -----
From: "Greg Sheremeta" <gshereme@redhat.com> To: "devel" <devel@ovirt.org> Sent: Monday, November 28, 2016 7:43:27 PM Subject: [ovirt-devel] performance improvements and gwt-rpc switch
Hi everyone,
For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin performance improvements. There have been some reports [1] [2] of UI sluggishness in both 3.6 and 4.0, usually after the browser had been open some time, and usually in scale environments.
After some research, we determined that the primary cause of this sluggishness was memory leaks.
We embarked on several weeks of hunting down memory leak bugs and squashing them. Alexander Wels and Vojtech Szocs led this work, and I helped test the performance of each patch as they created them. As they created patches to squash leaks, performance kept getting better and better. Today we've merged the last of our patches [*], and I'm happy to announce that we are now seeing much better UI performance on 4.1-master and 4.0.6.
Over the course of several hours with the browser window open, users should see no sluggishness at all.
[*] This last patch switches oVirt from using de-rpc to gwt-rpc in the frontend. This improves performance, but it also allows us to upgrade to GWT 2.8. We'd been previously blocked on that.
If you're interested in UI performance testing, continue reading. If not, you can stop here :)
.....
To verify our performance improvements, we took some simple measurements using selenium webdriver. The tests were unscientific, but very helpful. We ran a webdriver flow through oVirt that clicked some buttons and tabs and refreshed some grids. We did it a few hundred or thousand times. The tests were run using stubbed hosts (ovirt-vdsmfake) so that only the engine and UI were under test.
Below are the important takeaways. The x axis is time, and each point on a graph is a loop through the same webdriver flow. The (ms) y axes are response times, and memory is in MB.
In this graph, we compare oVirt 4.1 with and without our most impactful patch applied. As you can see, with the patch applied, response time stays flat for 200 loops of my test script over the course of 18 and 43 minutes. Without the patch applied, response time quickly degraded such that 200 loops of my test script took 1 hr 2 minutes vs. 18 minutes with the patch applied -- a 66% improvement!
In this graph [ignore the spike], we tested oVirt hard for 6 hours 25 minutes (2000 loops). As you can see, the response times stay relatively flat over 6 hours! This is a great improvement. Do note that the memory is still growing, albeit much more slowly now. You can see towards the end of this run, maybe around hour 5, that the deviation starts to go up (the line thickens). Takeaway: maybe refresh your browser after many hours of having webadmin open. But, this is a stress test -- I'm betting users won't notice this slowdown after even 6 hours of regular webadmin use or idling.
Last, here is a graph that shows gwt-rpc performing slightly better than de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster rpc implementation.
Reply with any questions or concerns. Thanks!
Best wishes, Greg
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
looks like great work has been done here. following QE validation and internal customers input assuming feedback is very positive and regressions are covered , i would like to take this information to our customers. would probably worth a post on rhev-tech. what are the exceptions for the performance boost due to the changes on 3.6 branch? On Wed, Nov 30, 2016 at 7:46 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Thanks Greg for the excellent write-up!
oVirt WebAdmin UI is quite complex, with lots of abstractions (the GWT technology being a Java-on-top-of-Web-APIs abstraction itself) as well as many features (and lots of dialogs..) so this task wasn't easy, but I guess we managed to get UI into a stabilized state now.
Dialogs (non-singleton by design) were a major source of memory leaks, so we added UI infra to ensure automatic dialog cleanup.
In 4.2, we'd like to upgrade GWT SDK version to latest stable (2.8.x) which will hopefully improve GWT compiler performance and, importantly, allow us to use Java 8 language features in our GWT UI code.
There's still potential for improvement, we're tracking that through:
[tracker] oVirt UI performance improvements https://bugzilla.redhat.com/1378935
(some IE-specific improvements are already submitted as part of ^^)
Regards, Vojtech
From: "Greg Sheremeta" <gshereme@redhat.com> To: "devel" <devel@ovirt.org> Sent: Monday, November 28, 2016 7:43:27 PM Subject: [ovirt-devel] performance improvements and gwt-rpc switch
Hi everyone,
For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin performance improvements. There have been some reports [1] [2] of UI sluggishness in both 3.6 and 4.0, usually after the browser had been open some time, and usually in scale environments.
After some research, we determined that the primary cause of this sluggishness was memory leaks.
We embarked on several weeks of hunting down memory leak bugs and squashing them. Alexander Wels and Vojtech Szocs led this work, and I helped test
performance of each patch as they created them. As they created patches to squash leaks, performance kept getting better and better. Today we've merged the last of our patches [*], and I'm happy to announce that we are now seeing much better UI performance on 4.1-master and 4.0.6.
Over the course of several hours with the browser window open, users should see no sluggishness at all.
[*] This last patch switches oVirt from using de-rpc to gwt-rpc in the frontend. This improves performance, but it also allows us to upgrade to GWT 2.8. We'd been previously blocked on that.
If you're interested in UI performance testing, continue reading. If not, you can stop here :)
.....
To verify our performance improvements, we took some simple measurements using selenium webdriver. The tests were unscientific, but very helpful. We ran a webdriver flow through oVirt that clicked some buttons and tabs and refreshed some grids. We did it a few hundred or thousand times. The tests were run using stubbed hosts (ovirt-vdsmfake) so that only the engine and UI were under test.
Below are the important takeaways. The x axis is time, and each point on a graph is a loop through the same webdriver flow. The (ms) y axes are response times, and memory is in MB.
In this graph, we compare oVirt 4.1 with and without our most impactful
----- Original Message ----- the patch
applied. As you can see, with the patch applied, response time stays flat for 200 loops of my test script over the course of 18 and 43 minutes. Without the patch applied, response time quickly degraded such that 200 loops of my test script took 1 hr 2 minutes vs. 18 minutes with the patch applied -- a 66% improvement!
In this graph [ignore the spike], we tested oVirt hard for 6 hours 25 minutes (2000 loops). As you can see, the response times stay relatively flat over 6 hours! This is a great improvement. Do note that the memory is still growing, albeit much more slowly now. You can see towards the end of this run, maybe around hour 5, that the deviation starts to go up (the line thickens). Takeaway: maybe refresh your browser after many hours of having webadmin open. But, this is a stress test -- I'm betting users won't notice this slowdown after even 6 hours of regular webadmin use or idling.
Last, here is a graph that shows gwt-rpc performing slightly better than de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster rpc implementation.
Reply with any questions or concerns. Thanks!
Best wishes, Greg
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
I'm working on 3.6 now. My expectation is that we can speed it up a bit, but it'll never be as fast as 4.0.6/4.1. Unless we decide to commit time to it, in which case we've proven that it can be done, it's just a matter of resources. Greg On Thu, Dec 1, 2016 at 4:30 AM, Moran Goldboim <mgoldboi@redhat.com> wrote:
looks like great work has been done here. following QE validation and internal customers input assuming feedback is very positive and regressions are covered , i would like to take this information to our customers. would probably worth a post on rhev-tech. what are the exceptions for the performance boost due to the changes on 3.6 branch?
On Wed, Nov 30, 2016 at 7:46 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
Thanks Greg for the excellent write-up!
oVirt WebAdmin UI is quite complex, with lots of abstractions (the GWT technology being a Java-on-top-of-Web-APIs abstraction itself) as well as many features (and lots of dialogs..) so this task wasn't easy, but I guess we managed to get UI into a stabilized state now.
Dialogs (non-singleton by design) were a major source of memory leaks, so we added UI infra to ensure automatic dialog cleanup.
In 4.2, we'd like to upgrade GWT SDK version to latest stable (2.8.x) which will hopefully improve GWT compiler performance and, importantly, allow us to use Java 8 language features in our GWT UI code.
There's still potential for improvement, we're tracking that through:
[tracker] oVirt UI performance improvements https://bugzilla.redhat.com/1378935
(some IE-specific improvements are already submitted as part of ^^)
Regards, Vojtech
From: "Greg Sheremeta" <gshereme@redhat.com> To: "devel" <devel@ovirt.org> Sent: Monday, November 28, 2016 7:43:27 PM Subject: [ovirt-devel] performance improvements and gwt-rpc switch
Hi everyone,
For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin performance improvements. There have been some reports [1] [2] of UI sluggishness in both 3.6 and 4.0, usually after the browser had been open some time, and usually in scale environments.
After some research, we determined that the primary cause of this sluggishness was memory leaks.
We embarked on several weeks of hunting down memory leak bugs and squashing them. Alexander Wels and Vojtech Szocs led this work, and I helped test
performance of each patch as they created them. As they created patches to squash leaks, performance kept getting better and better. Today we've merged the last of our patches [*], and I'm happy to announce that we are now seeing much better UI performance on 4.1-master and 4.0.6.
Over the course of several hours with the browser window open, users should see no sluggishness at all.
[*] This last patch switches oVirt from using de-rpc to gwt-rpc in the frontend. This improves performance, but it also allows us to upgrade to GWT 2.8. We'd been previously blocked on that.
If you're interested in UI performance testing, continue reading. If not, you can stop here :)
.....
To verify our performance improvements, we took some simple measurements using selenium webdriver. The tests were unscientific, but very helpful. We ran a webdriver flow through oVirt that clicked some buttons and tabs and refreshed some grids. We did it a few hundred or thousand times. The tests were run using stubbed hosts (ovirt-vdsmfake) so that only the engine and UI were under test.
Below are the important takeaways. The x axis is time, and each point on a graph is a loop through the same webdriver flow. The (ms) y axes are response times, and memory is in MB.
In this graph, we compare oVirt 4.1 with and without our most impactful
applied. As you can see, with the patch applied, response time stays flat for 200 loops of my test script over the course of 18 and 43 minutes. Without the patch applied, response time quickly degraded such that 200 loops of my test script took 1 hr 2 minutes vs. 18 minutes with the
applied -- a 66% improvement!
In this graph [ignore the spike], we tested oVirt hard for 6 hours 25 minutes (2000 loops). As you can see, the response times stay relatively flat over 6 hours! This is a great improvement. Do note that the memory is still growing, albeit much more slowly now. You can see towards the end of
----- Original Message ----- the patch patch this
run, maybe around hour 5, that the deviation starts to go up (the line thickens). Takeaway: maybe refresh your browser after many hours of having webadmin open. But, this is a stress test -- I'm betting users won't notice this slowdown after even 6 hours of regular webadmin use or idling.
Last, here is a graph that shows gwt-rpc performing slightly better than de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster rpc implementation.
Reply with any questions or concerns. Thanks!
Best wishes, Greg
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
--qwMfg6hGNb2FVpUXH2PlOtoqgusgWxriP Content-Type: multipart/mixed; boundary="1JtPtLK20L77Kd4WS1jDJUNO5e6CDirQ0"; protected-headers="v1" From: Sven Kieske <s.kieske@mittwald.de> To: devel@ovirt.org Message-ID: <1bdf0892-ce3a-45f1-6060-83b1170cd249@mittwald.de> Subject: Re: [ovirt-devel] performance improvements and gwt-rpc switch References: <CAEReEe8yXXvZKA9NDAt0VtiUZB_gCGP8Kuvsb6PB4rccf6xMhA@mail.gmail.com> <1824223935.881578.1480527996203.JavaMail.zimbra@redhat.com> <CANmG9291EDvr-vSpcHCan-MYpmT6NeT7Uy9k5tfyvphms7--Gg@mail.gmail.com> <CAEReEe-qWa3HkTUistwsH07cwzj+_h6uJTj=cguP_fex4_Fq+w@mail.gmail.com> In-Reply-To: <CAEReEe-qWa3HkTUistwsH07cwzj+_h6uJTj=cguP_fex4_Fq+w@mail.gmail.com> --1JtPtLK20L77Kd4WS1jDJUNO5e6CDirQ0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/12/16 16:27, Greg Sheremeta wrote:
I'm working on 3.6 now. My expectation is that we can speed it up a bit= , but it'll never be as fast as 4.0.6/4.1. Unless we decide to commit tim= e to it, in which case we've proven that it can be done, it's just a matter = of resources.
Sorry for getting a little offtopic, but I'm really confused: It was stated somewhere that 3.6.7 will be the last release, and there has not been an official 3.6. release since then, but otoh there seems to be ongoing work on 3.6, see: https://gerrit.ovirt.org/#/admin/projects/ovirt-engine,branches there are branches for 3.6.8 and 3.6.9 already. Will there be future 3.6 releases, or not? Or is this just work for downstream RHEV which will get support much longer? It would be nice if someone could clarify this. Personally I really would like to see additional 3.6.z releases, especially with these performance improvements around the webui. Thanks and sorry for hijacking this thread. --=20 Mit freundlichen Gr=FC=DFen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=F6nigsberger Stra=DFe 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch=E4ftsf=FChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause= n Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha= usen --1JtPtLK20L77Kd4WS1jDJUNO5e6CDirQ0-- --qwMfg6hGNb2FVpUXH2PlOtoqgusgWxriP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYQEsEAAoJEMby9TMDAbQRfRgQANNQkbsJEKxZHyyclHHwLKZM Cu49ETeqv5KUW002JDdfbeOPuYuFP1w+7BOf7CjeuFvyHgmkcWaocervLGgybpAE yieL95I2+R4WbkRuq/kLjZxkFdgxWR3BLFGBkyKoMtOPzlf14heGyCTYbYj+Fy8+ XMwJza1JCQQ2y7gZQnvRzwnFG3/7FsdMnqVx5mRerjFz7yF4MrHr/X1t3IIbCJWS o7UxXj1G0XHZeDMg60owPbC8dnWHwH5//j3Al2T/K+Sg6DBOMDV390M8zHNXmDms 71xGo3vCbSTd9yW4mw170fszpZQ06pOVfYGQUuNU7cK6F/MKSZDhE58XqpUZUq18 PPaZxK/KbWHhJzEUgWNFCWjIVZPruFS9Br824gkHqbdYIOxU/DZA+f94cbGcfOKO Rn1Z5GCqb2n5AN2ryKLRWsQitKXnLyGFd/KFMEzXuDDOhNWmnovCxQUxBQw0+Jd2 DAhVW3RV+Pybg8qKifwzr9JyHPQRrOSWOdyUivEyMpJVj9SPxdc9ObflnMVwkfuK etLB4FQBb5Ud/XeR9erjBj0H7l24elyKTV4VxAOta2AEpfTkf9Ilvb95fZOMICJ1 6AsoOLydT6uggTJKNTfcaMTmW+X0OrRvFUjw4iw4AJJ2BqRiLzvo28nZxMvY8DUq EyrlMM37XWqZW702+8Ud =GlFf -----END PGP SIGNATURE----- --qwMfg6hGNb2FVpUXH2PlOtoqgusgWxriP--
On Thu, Dec 1, 2016 at 6:08 PM, Sven Kieske <s.kieske@mittwald.de> wrote:
On 01/12/16 16:27, Greg Sheremeta wrote:
I'm working on 3.6 now. My expectation is that we can speed it up a bit, but it'll never be as fast as 4.0.6/4.1. Unless we decide to commit time to it, in which case we've proven that it can be done, it's just a matter of resources.
Sorry for getting a little offtopic, but I'm really confused:
It was stated somewhere that 3.6.7 will be the last release, and there has not been an official 3.6. release since then, but otoh there seems to be ongoing work on 3.6, see:
https://gerrit.ovirt.org/#/admin/projects/ovirt-engine,branches
there are branches for 3.6.8 and 3.6.9 already.
Will there be future 3.6 releases, or not?
we aren't planning to issue any upstream 3.6 based release
Or is this just work for downstream RHEV which will get support much longer?
that's right - it's part of the add value for our downstream/product customers.
It would be nice if someone could clarify this.
hope it helps. Regards, Moran. Personally I really would like to see additional 3.6.z releases,
especially with these performance improvements around the webui.
Thanks and sorry for hijacking this thread.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 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
On Thu, Dec 1, 2016 at 5:35 PM, Moran Goldboim <mgoldboi@redhat.com> wrote:
On Thu, Dec 1, 2016 at 6:08 PM, Sven Kieske <s.kieske@mittwald.de> wrote:
On 01/12/16 16:27, Greg Sheremeta wrote:
I'm working on 3.6 now. My expectation is that we can speed it up a bit, but it'll never be as fast as 4.0.6/4.1. Unless we decide to commit time to it, in which case we've proven that it can be done, it's just a matter of resources.
Sorry for getting a little offtopic, but I'm really confused:
It was stated somewhere that 3.6.7 will be the last release, and there has not been an official 3.6. release since then, but otoh there seems to be ongoing work on 3.6, see:
https://gerrit.ovirt.org/#/admin/projects/ovirt-engine,branches
there are branches for 3.6.8 and 3.6.9 already.
Will there be future 3.6 releases, or not?
we aren't planning to issue any upstream 3.6 based release
Or is this just work for downstream RHEV which will get support much longer?
that's right - it's part of the add value for our downstream/product customers.
Of course all changes done for downstream RHEV 3.6 are merged into upstream oVirt 3.6 repositories, so you can always build up-to-date oVirt 3.6 from source codes.
It would be nice if someone could clarify this.
hope it helps.
Regards, Moran.
Personally I really would like to see additional 3.6.z releases,
especially with these performance improvements around the webui.
Thanks and sorry for hijacking this thread.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (6)
-
Greg Sheremeta -
Martin Perina -
Moran Goldboim -
Sven Kieske -
Vojtech Szocs -
Yaniv Kaul