On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <eh...@redhat.com> wrote: > > > >> On 9 Jun 2017, at 19:44, Dan Kenigsberg <dan...@redhat.com> wrote: >> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <p...@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? _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
