MOM and hosted engine use the ping verb to verify the connection is
still OK. The RPC client did not have any reconnect logic in the past
(and I think it still does not..).

Martin

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