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

[Roy Golan]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170808/fe22b0b8/attachment.html>