<div dir="ltr">Petr, why do you need the ping verb? what are you after?<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 8 Aug 2017 at 11:54 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">> The proposed solution is focused on making sure a command does one thing 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 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 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 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 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 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>