11:43 a.m.
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(a)redhat.com
2:40 a.m.
On Mon, Nov 28, 2016 at 8:43 PM, Greg Sheremeta <gshereme(a)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(a)redhat.com
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:46 a.m.
On Tue, Nov 29, 2016 at 4:40 AM, Yaniv Kaul <ykaul(a)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.
[1] http://www.internettrafficreport.com/30day.htm
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
10:46 a.m.
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(a)redhat.com>
To: "devel" <devel(a)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(a)redhat.com
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2:30 a.m.
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(a)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
----- Original Message -----
> From: "Greg Sheremeta" <gshereme(a)redhat.com>
> To: "devel" <devel(a)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(a)redhat.com
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
8:27 a.m.
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(a)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(a)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
>
>
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme(a)redhat.com>
> > To: "devel" <devel(a)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(a)redhat.com
> >
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
9:08 a.m.
--qwMfg6hGNb2FVpUXH2PlOtoqgusgWxriP
Content-Type: multipart/mixed; boundary="1JtPtLK20L77Kd4WS1jDJUNO5e6CDirQ0";
protected-headers="v1"
From: Sven Kieske <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Message-ID: <1bdf0892-ce3a-45f1-6060-83b1170cd249(a)mittwald.de>
Subject: Re: [ovirt-devel] performance improvements and gwt-rpc switch
References: <CAEReEe8yXXvZKA9NDAt0VtiUZB_gCGP8Kuvsb6PB4rccf6xMhA(a)mail.gmail.com>
<1824223935.881578.1480527996203.JavaMail.zimbra(a)redhat.com>
<CANmG9291EDvr-vSpcHCan-MYpmT6NeT7Uy9k5tfyvphms7--Gg(a)mail.gmail.com>
<CAEReEe-qWa3HkTUistwsH07cwzj+_h6uJTj=cguP_fex4_Fq+w(a)mail.gmail.com>
In-Reply-To: <CAEReEe-qWa3HkTUistwsH07cwzj+_h6uJTj=cguP_fex4_Fq+w(a)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--
9:35 a.m.
On Thu, Dec 1, 2016 at 6:08 PM, Sven Kieske <s.kieske(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
10:07 a.m.
On Thu, Dec 1, 2016 at 5:35 PM, Moran Goldboim <mgoldboi(a)redhat.com> wrote:
On Thu, Dec 1, 2016 at 6:08 PM, Sven Kieske <s.kieske(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2700
days inactive
2703
days old
8 comments
6 participants
participants (6)
-
Greg Sheremeta -
Martin Perina -
Moran Goldboim -
Sven Kieske -
Vojtech Szocs -
Yaniv Kaul