[ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Martin Sivak]

But it isn't as I said already. And so we are keeping the ping code
and that is why vdsm needs to solve the setupNetworks/ping bug.

Martin

On Tue, Aug 8, 2017 at 2:50 PM, Roy Golan <rgolan at redhat.com> wrote:
> This is for 4.1 https://gerrit.ovirt.org/#/c/78916/ , track that, it should
> be in.
>
> On Tue, 8 Aug 2017 at 15:10 Martin Sivak <msivak at redhat.com> wrote:
>>
>> What stomp heartbeat? There is no such thing in the Python json rpc
>> client.
>>
>> Martin
>>
>> On Tue, Aug 8, 2017 at 1:04 PM, Roy Golan <rgolan at redhat.com> wrote:
>> > Why isn't the stomp heartbeat enough?
>> >
>> > On Tue, 8 Aug 2017 at 13:45 Martin Sivak <msivak at redhat.com> wrote:
>> >>
>> >> 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 at 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 at 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 at redhat.com>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer <nsoffer at redhat.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan <rgolan at 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 at 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 at ovirt.org
>> >> >> >>>> http://lists.ovirt.org/mailman/listinfo/devel
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> Devel mailing list
>> >> >> >>> Devel at ovirt.org
>> >> >> >>> http://lists.ovirt.org/mailman/listinfo/devel
>> >> >> >>
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Devel mailing list
>> >> >> >> Devel at ovirt.org
>> >> >> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Devel mailing list
>> >> >> > Devel at ovirt.org
>> >> >> > http://lists.ovirt.org/mailman/listinfo/devel
>> >> >> _______________________________________________
>> >> >> Devel mailing list
>> >> >> Devel at ovirt.org
>> >> >> http://lists.ovirt.org/mailman/listinfo/devel