<div dir="ltr">Why isn't the stomp heartbeat enough?<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 8 Aug 2017 at 13:45 Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">MOM and hosted engine use the ping verb to verify the connection is<br>
still OK. The RPC client did not have any reconnect logic in the past<br>
(and I think it still does not..).<br>
<br>
Martin<br>
<br>
On Tue, Aug 8, 2017 at 12:01 PM, Roy Golan <<a href="mailto:rgolan@redhat.com" target="_blank">rgolan@redhat.com</a>> wrote:<br>
> Petr, why do you need the ping verb? what are you after?<br>
><br>
> On Tue, 8 Aug 2017 at 11:54 Martin Sivak <<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>> wrote:<br>
>><br>
>> > The proposed solution is focused on making sure a command does one thing<br>
>> > and<br>
>> > not two:<br>
>> > A ping that has no side effects and a "watchdog" mechanism to confirm<br>
>> > connectivity.<br>
>><br>
>> This sounds as exactly the right solution right now.<br>
>><br>
>> >>> Still someone could call conirmConnectivity, no?<br>
>><br>
>> We do not protect any other endpoints that can cause the host to go<br>
>> wild (storage or even setupNetworks). I agree with Edward it is the<br>
>> responsibility of the caller to do the right thing. You need to be<br>
>> root or have the certificate to talk to VDSM anyway.<br>
>><br>
>> Martin<br>
>><br>
>> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas <<a href="mailto:ehaas@redhat.com" target="_blank">ehaas@redhat.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>> wrote:<br>
>> >><br>
>> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan <<a href="mailto:rgolan@redhat.com" target="_blank">rgolan@redhat.com</a>> wrote:<br>
>> >>><br>
>> >>> Still someone could call conirmConnectivity, no? so the state isn't<br>
>> >>> guarded from localhost tinkering anyhow. If you really need a solution<br>
>> >>> you<br>
>> >>> can acuire a token for this operation by setupNetworks, and confirm<br>
>> >>> connectivity with this token passed back.<br>
>> >>><br>
>> >>> I'm not sure about the severity of the problem here, I'll let other<br>
>> >>> reply, but I'm against this kind of solution.<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek <<a href="mailto:phoracek@redhat.com" target="_blank">phoracek@redhat.com</a>> wrote:<br>
>> >>>><br>
>> >>>> Hello,<br>
>> >>>><br>
>> >>>> current VDSM ping verb has a problem - it confirms network<br>
>> >>>> connectivity as a side-effect. After Engine calls setupNetwork it<br>
>> >>>> pings VDSM host to confirm that external network connectivity is not<br>
>> >>>> broken. This prohibits other users to call ping from localhost since<br>
>> >>>> it would confirm connectivity even though networking could be broken.<br>
>> >><br>
>> >><br>
>> >> Vdsm can save the client ip setting up the network. Getting a ping from<br>
>> >> this<br>
>> >> client can confirm that the connectivity was restored. pings from other<br>
>> >> hosts<br>
>> >> can be ignored.<br>
>> >><br>
>> >> The client address is available in a thread local variable<br>
>> >> (context.client_host)<br>
>> >> during all api calls. see vdsm.common.api.context_string() for example<br>
>> >> usage.<br>
>> >><br>
>> >> This infrastructure is available in 4.1.<br>
>> ><br>
>> ><br>
>> > The proposed solution is focused on making sure a command does one thing<br>
>> > and<br>
>> > not two:<br>
>> > A ping that has no side effects and a "watchdog" mechanism to confirm<br>
>> > connectivity.<br>
>> ><br>
>> > Does it make sense to confirm connectivity from localhost? In many cases<br>
>> > it<br>
>> > probably does not,<br>
>> > but there may be cases where it does make sense... it is not the<br>
>> > functionality to determine what<br>
>> > makes sense or not, it is the usage of it who has the responsibility to<br>
>> > use<br>
>> > it correctly.<br>
>> ><br>
>> >><br>
>> >> Nir<br>
>> >><br>
>> >>>><br>
>> >>>><br>
>> >>>> In order to fix this problem ping should be split to ping2 (which<br>
>> >>>> just<br>
>> >>>> returns Success with no side-effect) and confirmConnectivity. Change<br>
>> >>>> on VDSM side was introduced in [1], we still need to expose new verbs<br>
>> >>>> in Engine.<br>
>> >>>><br>
>> >>>> Regards,<br>
>> >>>> Petr<br>
>> >>>><br>
>> >>>> [1] <a href="https://gerrit.ovirt.org/#/c/80119/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/80119/</a><br>
>> >>>> _______________________________________________<br>
>> >>>> Devel mailing list<br>
>> >>>> <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
>> >>>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> Devel mailing list<br>
>> >>> <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
>> >>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> Devel mailing list<br>
>> >> <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
>> >> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Devel mailing list<br>
>> > <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
>> > <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
>> _______________________________________________<br>
>> Devel mailing list<br>
>> <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
</blockquote></div>