Re: [ovirt-devel] vdsm libs dependencies

On Sun, Jun 11, 2017 at 9:35 AM Edward Haas <ehaas(a)redhat.com&gt; wrote: > On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg <danken(a)redhat.com&gt; > wrote: > >> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <ehaas(a)redhat.com&gt; wrote: >> > >> > >> > >> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken(a)redhat.com&gt; wrote: >> >> >> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax(a)acronis.com&gt; >> 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 don't know about any dependency on network in storage, except the iscsi rp filter, which should be fixed by moving this functionality to common. > I have no plans for execCmd, it required too much changes for moving it > to common > execCmd will move to common soon, together will all the code under lib/vdsm/ We will not create another copy of execCmd, in common, we need to remove the unneeded copy under network instead.

> 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). > Why not move the ipwrapper module to common? This module should not have anything which with network business logic, just an easy way to run this command - just like udevadm, this does not belong to any subsystem.

> I do not think we should expose "ip route.." commands as vdsm-network api > (network.api), it feels wrong. > Pavel needs a way to detect if an ip address (ipv4/6) is the address of the local host, so we can use bind mount instead of regular mount. See https://gerrit.ovirt.org/68822 I don't see a need to depend on network package for this, this is not a service of the network package. If you think these should be a service of the network package, we need an entry point to access these apis.

Nir > > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel