2:49 p.m.
--_000_3ECE0CC4CC784D5C8DE6B77CDA7F189Aacroniscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
SGVsbG8sDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IGRlcGVuZGVuY2llcyBvZiB2ZHNtIGxp
YnJhcmllcy4gQ291bGQgc29tZWJvZHkgc3VnZ2VzdCBob3cgSSBjYW4gdXNlIHZkc20ubmV0d29y
ay5pcHdyYXBwZXIgZnJvbSB2ZHNtLnN0b3JhZ2U/DQoNClNwZWNpZmljYWxseSwgSSBuZWVkIGEg
d2F5IHRvIGRldGVybWluZSB0aGF0IGFuIElQIGFkZHJlc3Mgb2YgTkZTIHBhdGggaXMgbG9jYWwu
IFRoZSByaWdodCB3YXkgdG8gZGV0ZXJtaW5lIHRoYXQgaXMgYXMgc2ltcGxlIGFzIHRoZSBmb2xs
b3dpbmc6DQoNCiMgL3NiaW4vaXAgcm91dGUgZ2V0IFguWC5YLlggfCBncmVwIC1xIF5sb2NhbCAm
JiBlY2hvIElQIGlzIGxvY2FsDQoNClRoaXMgaXMgd2h5IEkgbmVlZCB0byB1c2UgdmRzbS5uZXR3
b3JrLmlwd3JhcHBlci4gU2VlIGRldGFpbHMgYXQgaHR0cHM6Ly9nZXJyaXQub3ZpcnQub3JnLyMv
Yy82ODgyMi8NCg0KVGhhbmtzDQoNCg==
--_000_3ECE0CC4CC784D5C8DE6B77CDA7F189Aacroniscom_
Content-Type: text/html; charset="utf-8"
Content-ID: <77AD686C8113B2458D846577C397B4F2(a)acronis.com>
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N
c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r
Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu
ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt
c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl
YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjIuMGNtIDQyLjVw
dCAyLjBjbSAzLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0Ii
IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBk
ZXBlbmRlbmNpZXMgb2YgdmRzbSBsaWJyYXJpZXMuIENvdWxkIHNvbWVib2R5IHN1Z2dlc3QgaG93
IEkgY2FuIHVzZSB2ZHNtLm5ldHdvcmsuaXB3cmFwcGVyIGZyb20gdmRzbS5zdG9yYWdlPzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij5TcGVjaWZpY2FsbHksIEkgbmVlZCBhIHdheSB0byBkZXRlcm1pbmUgdGhhdCBhbiBJ
UCBhZGRyZXNzIG9mIE5GUyBwYXRoIGlzIGxvY2FsLiBUaGUgcmlnaHQgd2F5IHRvIGRldGVybWlu
ZSB0aGF0IGlzIGFzIHNpbXBsZSBhcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4jIC9zYmlu
L2lwIHJvdXRlIGdldCBYLlguWC5YIHwgZ3JlcCAtcSBebG9jYWwgJmFtcDsmYW1wOyBlY2hvIElQ
IGlzIGxvY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMgaXMgd2h5IEkgbmVlZCB0byB1c2UgdmRzbS5uZXR3
b3JrLmlwd3JhcHBlci4gU2VlIGRldGFpbHMgYXQNCjxhIGhyZWY9Imh0dHBzOi8vZ2Vycml0Lm92
aXJ0Lm9yZy8jL2MvNjg4MjIvIj5odHRwczovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzY4ODIyLzwv
YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==
--_000_3ECE0CC4CC784D5C8DE6B77CDA7F189Aacroniscom_--
7:44 p.m.
On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax(a)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.
10:09 p.m.
On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken(a)redhat.com>
wrote:
> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax(a)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.
Thanks,
Edy.
1:27 a.m.
On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <ehaas(a)redhat.com> wrote:
> On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken(a)redhat.com> wrote:
>
>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax(a)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?
9:34 a.m.
On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <ehaas(a)redhat.com>
wrote:
>
>
>
>> On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken(a)redhat.com> wrote:
>>
>>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax(a)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 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.
12:50 p.m.
On Sun, Jun 11, 2017 at 9:35 AM Edward Haas <ehaas(a)redhat.com> wrote:
On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg
<danken(a)redhat.com> wrote:
> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <ehaas(a)redhat.com> wrote:
> >
> >
> >
> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken(a)redhat.com> wrote:
> >>
> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev <Pax(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
1:13 p.m.
On Sun, Jun 11, 2017 at 12:50 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Sun, Jun 11, 2017 at 9:35 AM Edward Haas <ehaas(a)redhat.com>
wrote:
> On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg <danken(a)redhat.com>
> wrote:
>
>> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas <ehaas(a)redhat.com> wrote:
>> >
>> >
>> >
>> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg <danken(a)redhat.com>
wrote:
>> >>
>> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev
<Pax(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
2721
days inactive
2723
days old
6 comments
4 participants
participants (4)
-
Dan Kenigsberg -
Edward Haas -
Nir Soffer -
Pavel Gashev