On Mon, Aug 7, 2017 at 5:28 PM Roy Golan <rgo...@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 <phora...@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. 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