Re: [ovirt-devel] vdsm libs dependencies

[Edward Haas]

On Sun, Jun 11, 2017 at 12:50 PM, Nir Soffer  wrote:

> On Sun, Jun 11, 2017 at 9:35 AM Edward Haas  wrote:
>
>> On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg 
>> wrote:
>>
>>> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas  wrote:
>>> >
>>> >
>>> >
>>> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
>>> >>
>>> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev 
>>> 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@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm libs dependencies

[Nir Soffer]

On Sun, Jun 11, 2017 at 9:35 AM Edward Haas  wrote:

> On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg  wrote:
>
>> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas  wrote:
>> >
>> >
>> >
>> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
>> >>
>> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm libs dependencies

[Edward Haas]

> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
> 
>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev  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.

Thanks,
Edy.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm libs dependencies

[Edward Haas]

On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg  wrote:

> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas  wrote:
> >
> >
> >
> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
> >>
> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev  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 have no plans for execCmd, it required too much changes for moving it to
common 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).
I do not think we should expose "ip route.." commands as vdsm-network api
(network.api), it feels wrong.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm libs dependencies

[Dan Kenigsberg]

On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas  wrote:
>
>
>
>> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
>>
>>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev  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

Re: [ovirt-devel] vdsm libs dependencies

[Dan Kenigsberg]

On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev  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.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] vdsm libs dependencies

[Pavel Gashev]

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/

Thanks

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel