Re: [ovirt-devel] vdsm libs dependencies
On Fri, Jun 9, 2017 at 10:09 PM, Edward Haaswrote: > > > >> 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
On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashevwrote: > 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
On Thu, Jun 8, 2017 at 11:16 PM, Greg Sheremetawrote: > > 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
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