On Sun, Jun 11, 2017 at 12:50 PM, Nir Soffer <[email protected]> wrote:
> On Sun, Jun 11, 2017 at 9:35 AM Edward Haas <[email protected]> wrote: > >> 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 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. > I do not see this happening any-time soon unless you know anyone who took this task on himself. Network has now a very simple version as it does not need any special functionality. > > >> 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. > Because ipwrapper does 100 things and you now just need 1 of those. We should move to common only heavy used functionality with enough complexity to be worth it. Contaminating common with too much noise is also bad, we need some balance. > >> 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 >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/devel > >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
