Re: [ovirt-devel] vdsm libs dependencies

2017-06-09 Thread 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

2017-06-09 Thread 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


Re: [ovirt-devel] GWT symbol maps are now installed with Engine, the "debuginfo" packages are out

2017-06-09 Thread Vojtech Szocs
On Thu, Jun 8, 2017 at 11:16 PM, Greg Sheremeta  wrote:

>
> On Thu, Jun 8, 2017 at 3:50 PM, Martin Perina  wrote:
>
>>
>>
>> On Thu, Jun 8, 2017 at 7:37 PM, Greg Sheremeta 
>> wrote:
>>
>>> Yes, they'll now be in ui.log on the server.
>>>
>>> Greg
>>>
>>>
>>> On Thu, Jun 8, 2017 at 1:32 PM, Shmuel Melamud 
>>> wrote:
>>>
 Hi!

 When building the Engine manually, is it possible to get de-obfuscated
 stack traces without rebuilding with DEV_BUILD_GWT_DRAFT=1 ?

 Shmuel

 On Thu, Jun 8, 2017 at 8:17 PM, Vojtech Szocs 
 wrote:
 > Hello everyone,
 >
 > in master [1] and 4.1 [2] branches, meaningful (de-obfuscated)
 GWT/Java
 > stack traces are now available right after Engine installation or
 upgrade.
 >
 > There's no need to install the complementary "debuginfo" packages
 anymore.
 > In fact, those packages are removed now. (If installed, please remove
 them
 > manually before upgrading Engine.)

>>>
>> ​This is bad, we should not require manual uninstallation during
>> upgrades. Could you please
>> add​
>>
>> ​correct Provides/Conflicts into webadmin/userportal packages, so
>> existing debuginfo
>> packages will be uninstalled automatically?
>>
>
> Normally it is probably bad. We discussed this in the patch comments.
> Quoting Sandro [3]:
>
> """
> about yum update error messages related to version locking:
> debug packages are not meant to be installed on any production
> environment other than for debugging purpose.
> Once the debug is finished they need to be removed.
> """
>

Right, ​those "debuginfo" packages are complementary and expected to be
removed once no longer needed (e.g. after collecting GWT/Java stack trace
information when reporting a UI related bug).

As Greg wrote, this was discussed in patch [1], please see the review
comments from Simone, Sandro and Didi.


> See the patch [1] for more of the conversation.
>
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1401963#c23
>
> Greg
>
>
>> ​
>>
>>> >
 > Please refer to commit msg for details.
 >
 > [1] https://gerrit.ovirt.org/#/c/75420
 > [2] https://gerrit.ovirt.org/#/c/77892/
 >
 > Regards,
 > Vojtech
 >
 >
 > ___
 > 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

>>>
>>>
>>>
>>> --
>>> Greg Sheremeta, MBA
>>> Sr. Software Engineer
>>> Red Hat, Inc.
>>> gsher...@redhat.com
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
>
> --
> Greg Sheremeta, MBA
> Sr. Software Engineer
> Red Hat, Inc.
> gsher...@redhat.com
>
> ___
> 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

[ovirt-devel] vdsm libs dependencies

2017-06-09 Thread 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