<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <<a href="mailto:ehaas@redhat.com">ehaas@redhat.com</a>> wrote:<br>
><br>
><br>
><br>
>> On 9 Jun 2017, at 19:44, Dan Kenigsberg <<a href="mailto:danken@redhat.com">danken@redhat.com</a>> wrote:<br>
>><br>
>>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <<a href="mailto:Pax@acronis.com">Pax@acronis.com</a>> wrote:<br>
>>> Hello,<br>
>>><br>
>>><br>
>>><br>
>>> I have a question about dependencies of vdsm libraries. Could somebody<br>
>>> suggest how I can use vdsm.network.ipwrapper from vdsm.storage?<br>
>>><br>
>>><br>
>>><br>
>>> Specifically, I need a way to determine that an IP address of NFS path is<br>
>>> local. The right way to determine that is as simple as the following:<br>
>>><br>
>>><br>
>>><br>
>>> # /sbin/ip route get X.X.X.X | grep -q ^local && echo IP is local<br>
>>><br>
>>><br>
>>><br>
>>> This is why I need to use vdsm.network.ipwrapper. See details at<br>
>>> <a href="https://gerrit.ovirt.org/#/c/68822/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>68822/</a><br>
>><br>
>> I think that we should create a new<br>
>> vdsm.network.api.is_local_<wbr>address() for this. Do you have a better<br>
>> idea, Edy?<br>
>><br>
>> P.S I just notice that we have a similar problem in already merged to iscsi.py:<br>
>><br>
>> from vdsm.network.netinfo.routes import getRouteDeviceTo<br>
>><br>
>> should be similarly avoided.<br>
><br>
> 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.<br>
><br>
> 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.<br>
> This could fit a helper in common.network, but we'll need execCmd moved to common first.<br>
<br>
</span>I'd like to assist Paval ASAP, and removing the storage dep on network<br>
internal is also urgent for the task of network separation. Do we have<br>
a short timeline for moving execCmd? If not, would you consider ad-hoc<br>
api entries?<br></blockquote><div><br></div><div>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.<br></div><div>I have no plans for execCmd, it required too much changes for moving it to common and we found a workaround (network.cmd).<br></div><div>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).<br></div><div>I do not think we should expose "ip route.." commands as vdsm-network api (network.api), it feels wrong.<br></div><div><br></div></div><br></div></div>