[ovirt-devel] vdsm libs dependencies

[Edward Haas]

On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg <danken at redhat.com> wrote:

> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <ehaas at redhat.com> wrote:
> >
> >
> >
> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken at redhat.com> wrote:
> >>
> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax at acronis.com> wrote:
> >>> Hello,
> >>>
> >>>
> >>>
> >>> I have a question about dependencies of vdsm libraries. Could somebody
> >>> suggest how I can use vdsm.network.ipwrapper from vdsm.storage?
> >>>
> >>>
> >>>
> >>> Specifically, I need a way to determine that an IP address of NFS path
> is
> >>> local. The right way to determine that is as simple as the following:
> >>>
> >>>
> >>>
> >>> # /sbin/ip route get X.X.X.X | grep -q ^local && echo IP is local
> >>>
> >>>
> >>>
> >>> This is why I need to use vdsm.network.ipwrapper. See details at
> >>> https://gerrit.ovirt.org/#/c/68822/
> >>
> >> I think that we should create a new
> >> vdsm.network.api.is_local_address() for this. Do you have a better
> >> idea, Edy?
> >>
> >> P.S I just notice that we have a similar problem in already merged to
> iscsi.py:
> >>
> >> from vdsm.network.netinfo.routes import getRouteDeviceTo
> >>
> >> should be similarly avoided.
> >
> > Anyone outside the network subtree accessing anything except the api
> module is in risk, as internals may be changed or removed. It is equivalent
> to accessing a private attribute in python.
> >
> > In general I am not in favor of contacting the network package for
> things that are not really its main business logic. Asking it if an IP is
> under one of the networks it manages seems fine, but asking this in general
> for the host is something else.
> > This could fit a helper in common.network, but we'll need execCmd moved
> to common first.
>
> I'd like to assist Paval ASAP, and removing the storage dep on network
> internal is also urgent for the task of network separation. Do we have
> a short timeline for moving execCmd? If not, would you consider ad-hoc
> api entries?
>

It's actually not urgent for network separation, storage is dependent on
network anyway and it is part of it's strategy on how to separate itself.
I have no plans for execCmd, it required too much changes for moving it to
common and we found a workaround (network.cmd).
We could implement a simple local exec command using C/Popen under
common.network if you are ok with it. And we will need to implement part of
the parsing (or use grep as suggested).
I do not think we should expose "ip route.." commands as vdsm-network api
(network.api), it feels wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170611/6fb451f8/attachment.html>