oVirt 4.2.0 GA status

We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30 Please review and either approve the blcoker or postpone to 4.2.1. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client? Thanks Martin On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.

On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
According to https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9 It works in Irit example, at least on that host with that load and timings, setting nr_retries=2 and _timeout=20 While we have _timeout=5 and no custom nr_retries https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_eng... So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.

On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
According to https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9 It works in Irit example, at least on that host with that load and timings, setting nr_retries=2 and _timeout=20
While we have _timeout=5 and no custom nr_retries https://github.com/oVirt/ovirt-hosted-engine-ha/blob/ master/ovirt_hosted_engine_ha/lib/util.py#L417
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.
-- IRIT GOIHMAN SOFTWARE ENGINEER EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> @redhatnews <https://twitter.com/redhatnews> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc>

So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
What does happen when only timeout is specified and the connection fails after the command is sent? What are the defaults in that case? Martin On Tue, Dec 19, 2017 at 1:55 PM, Irit Goihman <igoihman@redhat.com> wrote:
On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
According to https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9 It works in Irit example, at least on that host with that load and timings, setting nr_retries=2 and _timeout=20
While we have _timeout=5 and no custom nr_retries https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_eng...
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155InfravdsmBindings-APIigoihman@redhat.comNEWjsonrpc reconnect logic does not work and gets stuckurgentunspecifiedovirt-4.2.004:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA
TRIED. TESTED. TRUSTED.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.
--
IRIT GOIHMAN
SOFTWARE ENGINEER
EMEA VIRTUALIZATION R&D
Red Hat EMEA
TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat

On Tue, Dec 19, 2017 at 2:05 PM, Martin Sivak <msivak@redhat.com> wrote:
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
What does happen when only timeout is specified and the connection fails after the command is sent? What are the defaults in that case?
Timeout defines how long we are going to wait for a response. It is there in the code for a bit of time already and it is not related to reconnect. The only control that we expose for reconnect is number of retires.
Martin
On Tue, Dec 19, 2017 at 1:55 PM, Irit Goihman <igoihman@redhat.com> wrote:
On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
According to https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9 It works in Irit example, at least on that host with that load and timings, setting nr_retries=2 and _timeout=20
While we have _timeout=5 and no custom nr_retries https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_eng...
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155InfravdsmBindings-APIigoihman@redhat.comNEWjsonrpc reconnect logic does not work and gets stuckurgentunspecifiedovirt-4.2.004:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA
TRIED. TESTED. TRUSTED.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.
--
IRIT GOIHMAN
SOFTWARE ENGINEER
EMEA VIRTUALIZATION R&D
Red Hat EMEA
TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

The only control that we expose for reconnect is number of retires.
Right, but what is the default value? Because I see reconnect attempt even with no nr_retries and no timeout provided and then it gets stuck (or waiting for a really long timeout). Martin On Tue, Dec 19, 2017 at 2:28 PM, Piotr Kliczewski <piotr.kliczewski@gmail.com> wrote:
On Tue, Dec 19, 2017 at 2:05 PM, Martin Sivak <msivak@redhat.com> wrote:
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
What does happen when only timeout is specified and the connection fails after the command is sent? What are the defaults in that case?
Timeout defines how long we are going to wait for a response. It is there in the code for a bit of time already and it is not related to reconnect.
The only control that we expose for reconnect is number of retires.
Martin
On Tue, Dec 19, 2017 at 1:55 PM, Irit Goihman <igoihman@redhat.com> wrote:
On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
According to https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9 It works in Irit example, at least on that host with that load and timings, setting nr_retries=2 and _timeout=20
While we have _timeout=5 and no custom nr_retries https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_eng...
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote: > > We have a proposed blocker for the release: > 1527155InfravdsmBindings-APIigoihman@redhat.comNEWjsonrpc reconnect logic does not work and gets stuckurgentunspecifiedovirt-4.2.004:30:30 > > Please review and either approve the blcoker or postpone to 4.2.1. > Thanks, > > > -- > > SANDRO BONAZZOLA > > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > > Red Hat EMEA > > TRIED. TESTED. TRUSTED. > > > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.
--
IRIT GOIHMAN
SOFTWARE ENGINEER
EMEA VIRTUALIZATION R&D
Red Hat EMEA
TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

On Tue, Dec 19, 2017 at 2:05 PM, Martin Sivak <msivak@redhat.com> wrote:
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
What does happen when only timeout is specified and the connection fails after the command is sent? What are the defaults in that case?
So, there are not magic numbers to fit all, here's the description of those parameters: nr_retries - number of reconnection retries - if not specified than defualt is 1 _timeout - it's maximum time to wait for reply of a command/veb if client is connected - this does not affect reconnection any way, meaning the client could reconnect for example for 10 minutes (using high enough nr_retries value) and yet this timeout may not be reached So here are 2 suggestions: 1. Set nr_retries=0 and client will behave the same way as in 4.1 (meaning no reconnection performed) 2. Set nr_retries to high enough number (for example 100 000) and hope that this number of retries is enough for host being deployed using host deploy. I know that setting this number is tricky for HE, because the host deploy can take really different amount of time, but there's no exact way how to define exact timeout of single reconnection as it depends to the failure during attempt to connect. AFAIK no other functionality was mentioned in [1], so nothing else is implemented. If there are other requirement for reconnection functionality, then let's open a new RFE for that and discuss it Thanks Martin [1] https://bugzilla.redhat.com/show_bug.cgi?id=1376843
Martin
On Tue, Dec 19, 2017 at 1:55 PM, Irit Goihman <igoihman@redhat.com> wrote:
On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi <stirabos@redhat.com>
On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com>
wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of
wrote: the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
According to https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9 It works in Irit example, at least on that host with that load and
timings, setting nr_retries=2 and _timeout=20
While we have _timeout=5 and no custom nr_retries https://github.com/oVirt/ovirt-hosted-engine-ha/blob/
master/ovirt_hosted_engine_ha/lib/util.py#L417
So I think that we still have to fix it somehow. Are we really sure that nr_retries=2 and _timeout=20 are really the
magic numbers that works on every conditions?
No, it should be tested on HE environment and it depends on your usage.
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com>
wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <
sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155InfravdsmBindings-APIigoihman@redhat.comNEWjsonrpc reconnect
logic does not work and gets stuckurgentunspecifiedovirt-4.2.004:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA
TRIED. TESTED. TRUSTED.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.
--
IRIT GOIHMAN
SOFTWARE ENGINEER
EMEA VIRTUALIZATION R&D
Red Hat EMEA
TRIED. TESTED. TRUSTED. @redhatnews Red Hat Red Hat
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.

There is no misuse when optional argument is not used. But hosted engine uses the timeout parameter anyway so you can assume it is not a blocker for us. Martin On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.

Based on the above, removing the blocker flag from the bug. On Tue, Dec 19, 2017 at 3:03 PM, Martin Sivak <msivak@redhat.com> wrote:
There is no misuse when optional argument is not used. But hosted engine uses the timeout parameter anyway so you can assume it is not a blocker for us.
Martin
On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.

2017-12-19 15:15 GMT+01:00 Oved Ourfali <oourfali@redhat.com>:
Based on the above, removing the blocker flag from the bug.
Thanks. So current status is RC3 has no known blockers. I'll send a go/no go email for releasing GA tomorrow.
On Tue, Dec 19, 2017 at 3:03 PM, Martin Sivak <msivak@redhat.com> wrote:
There is no misuse when optional argument is not used. But hosted engine uses the timeout parameter anyway so you can assume it is not a blocker for us.
Martin
On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina <mperina@redhat.com> wrote:
As Irit mentioned the provided reproduction steps are wrong (misuse of the code) and she posted correct example showing that jsonrpc code works as expected. So Martin/Simone are you using somewhere in HE code the original example that is misusing the client?
Thanks
Martin
On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali <oourfali@redhat.com> wrote:
From the latest comment it doesn't seem like a blocker to me. Martin S. - your thoughts?
On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman@redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30
Please review and either approve the blcoker or postpone to 4.2.1. Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Martin Perina Associate Manager, Software Engineering Red Hat Czech s.r.o.
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
participants (7)
-
Irit Goihman
-
Martin Perina
-
Martin Sivak
-
Oved Ourfali
-
Piotr Kliczewski
-
Sandro Bonazzola
-
Simone Tiraboschi