On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg <[email protected]> wrote:
> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <[email protected]> wrote: > > > > > > > >> On 9 Jun 2017, at 19:44, Dan Kenigsberg <[email protected]> wrote: > >> > >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <[email protected]> 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.
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
