<div dir="ltr">This is for 4.1 <a href="https://gerrit.ovirt.org/#/c/78916/">https://gerrit.ovirt.org/#/c/78916/</a> , track that, it should be in. <br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 8 Aug 2017 at 15:10 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">What stomp heartbeat? There is no such thing in the Python json rpc client.<br>
<br>
Martin<br>
<br>
On Tue, Aug 8, 2017 at 1:04 PM, Roy Golan <<a href="mailto:rgolan@redhat.com" target="_blank">rgolan@redhat.com</a>> wrote:<br>
> Why isn't the stomp heartbeat enough?<br>
><br>
> On Tue, 8 Aug 2017 at 13:45 Martin Sivak <<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>> wrote:<br>
>><br>
>> 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<br>
>> >> > 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>><br>
>> >> > 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<br>
>> >> >>> 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>><br>
>> >> >>> 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<br>
>> >> >>>> not<br>
>> >> >>>> broken. This prohibits other users to call ping from localhost<br>
>> >> >>>> since<br>
>> >> >>>> it would confirm connectivity even though networking could be<br>
>> >> >>>> broken.<br>
>> >> >><br>
>> >> >><br>
>> >> >> Vdsm can save the client ip setting up the network. Getting a ping<br>
>> >> >> from<br>
>> >> >> this<br>
>> >> >> client can confirm that the connectivity was restored. pings from<br>
>> >> >> 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<br>
>> >> >> 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<br>
>> >> > 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<br>
>> >> > 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<br>
>> >> > 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.<br>
>> >> >>>> Change<br>
>> >> >>>> on VDSM side was introduced in [1], we still need to expose new<br>
>> >> >>>> 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>