Hi,
I'm aware of the difference in these modules and that the gi module is
deprecated, however from what I've gathered the new PyGObject module is either
not fully complete yet, or doesn't have the ability to access NetworkManager
like gi.repository does. Another possibility is that it's just not documented.
I agree that we shouldn't use deprecated packages, but I was unable to use
the new package for what I've wanted, so I used the old one. The reason being,
all the NetworkManager examples are using this package.
Anyway, I imported the module only to access a few value constants, and don't
actually use any functions it implements so if there is a way to do this with
the PyGObject package I have no problem with using this instead of the old
package.
I can look into it once I get back.
-Ondrej
----- Original Message -----
From: Jan Tluka <jtluka(a)redhat.com>
To: olichtne(a)redhat.com
Cc: lnst-developers(a)lists.fedorahosted.org
Sent: Mon, 08 Jul 2013 10:14:11 -0400 (EDT)
Subject: Re: [PATCH 0/3] Experimental NetworkManager support
Hi, I'm trying to use LNST with this patch set applied on RHEL6. There's
gi python module in python2.7 so I looked around on the internet and
found it [1] however the page says that this package has been deprecated
by GObject module [2].
I haven't investigated this further but my first impression is that we
should not stick to something that's in deprecated status and what would
not be fixed or updated in future. Or is there any reason why to use gi
instead of GObject?
-Jan
[1]
http://wiki.gnome.org/PyGI
[2]
http://live.gnome.org/PyGObject
Thu, Jul 04, 2013 at 01:25:30PM CEST, olichtne(a)redhat.com wrote:
From: Ondrej Lichtner <olichtne(a)redhat.com>
The following patch set adds experimental support for configuring network
interfaces with NetworkManager.
From what I've tested some uses work pretty nicely, others are more problematic.
I've had problems with bridge interfaces, that could be because, from what I can
see the bridge implementation is not complete in NM, or just because I didn't
have enough time to properly test it.
Macvlan and team are not yet supported, so lnst will probably break when trying
to test these while using NM.
NM will be used automatically when detected, and for now it doesn't mix with the
iptools configuration.
You can disable the usage of NM by setting
[environment]
use_nm=False
in the configuration files on slave machines.
Ondrej Lichtner (3):
Slave: add NmConfigDevice
Slave: use NmConfigDevice when NM is running
Slave Config: add option use_nm
lnst/Common/Config.py | 5 +
lnst/Slave/NetConfig.py | 16 +-
lnst/Slave/NetConfigDevice.py | 32 ++-
lnst/Slave/NetTestSlave.py | 15 +-
lnst/Slave/NmConfigDevice.py | 541 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 588 insertions(+), 21 deletions(-)
create mode 100644 lnst/Slave/NmConfigDevice.py
--
1.8.1.4
_______________________________________________
LNST-developers mailing list
LNST-developers(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/lnst-developers