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

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(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > > Why isn't the stomp heartbeat enough? > > > > On Tue, 8 Aug 2017 at 13:45 Martin Sivak <msivak(a)redhat.com&gt; 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(a)redhat.com&gt; wrote: > >> > Petr, why do you need the ping verb? what are you after? > >> > > >> > On Tue, 8 Aug 2017 at 11:54 Martin Sivak <msivak(a)redhat.com&gt; 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(a)redhat.com&gt; > >> >> wrote: > >> >> > > >> >> > > >> >> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer <nsoffer(a)redhat.com&gt; > >> >> > wrote: > >> >> >> > >> >> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan <rgolan(a)redhat.com&gt; > >> >> >> 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(a)redhat.com&gt; > >> >> >>> 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(a)ovirt.org > >> >> >>>> http://lists.ovirt.org/mailman/listinfo/devel > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> Devel mailing list > >> >> >>> Devel(a)ovirt.org > >> >> >>> http://lists.ovirt.org/mailman/listinfo/devel > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Devel mailing list > >> >> >> Devel(a)ovirt.org > >> >> >> http://lists.ovirt.org/mailman/listinfo/devel > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Devel mailing list > >> >> > Devel(a)ovirt.org > >> >> > http://lists.ovirt.org/mailman/listinfo/devel > >> >> _______________________________________________ > >> >> Devel mailing list > >> >> Devel(a)ovirt.org > >> >> http://lists.ovirt.org/mailman/listinfo/devel