[ovirt-devel] vdsm libs dependencies

[Edward Haas]

On Sun, Jun 11, 2017 at 12:50 PM, Nir Soffer <nsoffer at redhat.com> wrote:

> On Sun, Jun 11, 2017 at 9:35 AM Edward Haas <ehaas at redhat.com> wrote:
>
>> On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg <danken at redhat.com>
>> wrote:
>>
>>> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <ehaas at redhat.com> wrote:
>>> >
>>> >
>>> >
>>> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken at redhat.com> wrote:
>>> >>
>>> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax at 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?
>>>
>>
>> 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
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170611/7181fc83/attachment-0001.html>