Hi, according to https://bugzilla.redhat.com/show_bug.cgi?id=1673058 the network throughput usage increases by a x5 upgrading from Gluster 3.12 to Gluster 5.y. This seems definitively problematic on our hyper-converged environments: I read more than one report where, over 1 Gbps network, sanlock could not be refreshed quickly enough and so killed the engine VM if not rebooted the host due to the watchdog. This is probably due to the fact that, according to that bug, the network got completely saturated. Faster networks seems still fine. https://bugzilla.redhat.com/show_bug.cgi?id=1673058 is probably going to be solved for Gluster 5.6. On the other side we have https://bugzilla.redhat.com/1693998 <https://bugzilla.redhat.com/show_bug.cgi?id=1693998> about rebasing over Gluster 6 which seems not affected by that issue. Do you have concrete plans about testing oVirt with Gluster 6? thanks, Simone

Il giorno ven 5 apr 2019 alle ore 12:56 Gobinda Das <godas(a)redhat.com&gt; ha scritto: > Hi Simone, > Kaustav has upgraded from gluster-3.12 to gluster-6 and done some tests > like VM creation and some pg bench testing. > https://github.com/ezio-auditore/gluster-pg-bench-test-results > But yeah as you said will have to plan for end to end testing with fresh > installation also. > Gobinda, Sahina, Kaustav, any update on this testing? Are we ok to go with pushing the switch to Gluster 6 to master? One month passed and it's time to go on with this. > > > On Fri, Apr 5, 2019 at 3:31 PM Simone Tiraboschi <stirabos(a)redhat.com&gt; > wrote: > >> Hi, >> according to https://bugzilla.redhat.com/show_bug.cgi?id=1673058 the >> network throughput usage increases by a x5 upgrading from Gluster 3.12 to >> Gluster 5.y. >> >> This seems definitively problematic on our hyper-converged environments: >> I read more than one report where, over 1 Gbps network, sanlock could not >> be refreshed quickly enough and so killed the engine VM if not rebooted the >> host due to the watchdog. >> This is probably due to the fact that, according to that bug, the >> network got completely saturated. >> Faster networks seems still fine. >> https://bugzilla.redhat.com/show_bug.cgi?id=1673058 is probably going >> to be solved for Gluster 5.6. >> >> On the other side we have https://bugzilla.redhat.com/1693998 >> <https://bugzilla.redhat.com/show_bug.cgi?id=1693998> about rebasing >> over Gluster 6 which seems not affected by that issue. >> Do you have concrete plans about testing oVirt with Gluster 6? >> >> thanks, >> Simone >> >> > > -- > > > Thanks, > Gobinda > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/RFNOOVJAYJN... > -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

On Apr 5, 2019, at 12:00 PM, Simone Tiraboschi <stirabos(a)redhat.com&gt; wrote: Hi, according to https://bugzilla.redhat.com/show_bug.cgi?id=1673058 <https://bugzilla.redhat.com/show_bug.cgi?id=1673058> the network throughput usage increases by a x5 upgrading from Gluster 3.12 to Gluster 5.y. This seems definitively problematic on our hyper-converged environments: I read more than one report where, over 1 Gbps network, sanlock could not be refreshed quickly enough and so killed the engine VM if not rebooted the host due to the watchdog. This is probably due to the fact that, according to that bug, the network got completely saturated. Faster networks seems still fine. https://bugzilla.redhat.com/show_bug.cgi?id=1673058 <https://bugzilla.redhat.com/show_bug.cgi?id=1673058> is probably going to be solved for Gluster 5.6. On the other side we have https://bugzilla.redhat.com/1693998 <https://bugzilla.redhat.com/show_bug.cgi?id=1693998> about rebasing over Gluster 6 which seems not affected by that issue. Do you have concrete plans about testing oVirt with Gluster 6?

thanks, Simone _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IVTYCFKCQ5P...

On Apr 9, 2019, at 4:36 PM, Sandro Bonazzola <sbonazzo(a)redhat.com&gt; wrote: Il giorno lun 8 apr 2019 alle ore 19:48 Simon Coter <simon.coter(a)oracle.com <mailto:simon.coter@oracle.com>> ha scritto: Hi all, > On Apr 5, 2019, at 12:00 PM, Simone Tiraboschi <stirabos(a)redhat.com <mailto:stirabos@redhat.com>> wrote: > > Hi, > according to https://bugzilla.redhat.com/show_bug.cgi?id=1673058 <https://bugzilla.redhat.com/show_bug.cgi?id=1673058> the network throughput usage increases by a x5 upgrading from Gluster 3.12 to Gluster 5.y. > > This seems definitively problematic on our hyper-converged environments: I read more than one report where, over 1 Gbps network, sanlock could not be refreshed quickly enough and so killed the engine VM if not rebooted the host due to the watchdog. > This is probably due to the fact that, according to that bug, the network got completely saturated. > Faster networks seems still fine. > https://bugzilla.redhat.com/show_bug.cgi?id=1673058 <https://bugzilla.redhat.com/show_bug.cgi?id=1673058> is probably going to be solved for Gluster 5.6. > > On the other side we have https://bugzilla.redhat.com/1693998 <https://bugzilla.redhat.com/show_bug.cgi?id=1693998> about rebasing over Gluster 6 which seems not affected by that issue. > Do you have concrete plans about testing oVirt with Gluster 6? based on bug above, any plan to switch to Gluster-6 with oVirt 4.3 ? We are tentatively targeting rebase on Gluster 6 for 4.3.5: https://bugzilla.redhat.com/show_bug.cgi?id=1693998 <https://bugzilla.redhat.com/show_bug.cgi?id=1693998> Plan can change while we test it. Simon > > thanks, > Simone > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> > To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ <https://www.ovirt.org/site/privacy-policy/> > oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> > List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IVTYCFKCQ5P... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IVTYCFKCQ5P... _______________________________________________ Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ <https://www.ovirt.org/site/privacy-policy/> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2RM2XMW5BV2... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2RM2XMW5BV2... -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <mailto:sbonazzo@redhat.com> <https://red.ht/sig> _______________________________________________ Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ <https://www.ovirt.org/site/privacy-policy/> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ <https://www.ovirt.org/community/about/community-guidelines/> List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/TENVEABIF7E... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/TENVEABIF7E...