[ovirt-devel] vdsm libs dependencies

[Nir Soffer]

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.


> 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.


> 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/77623736/attachment.html>