[RFC] Issue #650 - Kimchi & Network Manager
Hi, This is the information displayed when clicked "+" button in "network" tab with Network Manager enabled/running- "The bridged VLAN tag may not work well with NetworkManager enabled. You should consider disabling it." Are we advising end user to block Network Manager permanently? or only in certain circumstances we ask user to disable network manager temporarily? If former case, then how about the scenarios in which the user relays on network manager to do certain network operations? If it is the later case, then how about the configuration changes made by Network Manager for the bridge or vlan created by kimchi? I am not sure about the history behind disabling the network manager. I suppose Kimchi should not stop end user from using other network tools, at the same time tool should easily pick up any configuration done out side of the tool.
Hi Suresh, Actually we are warning the user about a possible failure when creating bridged VLAN with NM enabled. The reason is that NM doesn't support such scenario. I don't think Kimchi tries to stop users from using other tools but, IMHO, it's a good approach to let them know when such tools don't work as expected under determined circumstances. Best regards! On 01-09-2015 03:02, Suresh Babu Angadi wrote:
Hi, This is the information displayed when clicked "+" button in "network" tab with Network Manager enabled/running- "The bridged VLAN tag may not work well with NetworkManager enabled. You should consider disabling it."
Are we advising end user to block Network Manager permanently? or only in certain circumstances we ask user to disable network manager temporarily? If former case, then how about the scenarios in which the user relays on network manager to do certain network operations? If it is the later case, then how about the configuration changes made by Network Manager for the bridge or vlan created by kimchi?
I am not sure about the history behind disabling the network manager. I suppose Kimchi should not stop end user from using other network tools, at the same time tool should easily pick up any configuration done out side of the tool.
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM
On 09/01/2015 03:02 AM, Suresh Babu Angadi wrote:
Are we advising end user to block Network Manager permanently?
No. We are advising the user to exercise caution with NetworkManager in these scenarios. It is a known fact that NetworkManager started support native bridge and bonding only in F20*. This Kimchi feature must be supported on older distros such as RHEL 7.1 that has older NetworkManager versions that doesn't have this native support. This is why we have this warning. The user can proceed with the operation with NetworkManager on, but he's on his own. * https://docs.fedoraproject.org/en-US/Fedora/20/html/Release_Notes/sect-Relea...
Daniel, Ricardo I get your point. Network Manager does not support full features and not present in older versions before Fedora 20. It will be keep on updating to support more and more use cases. Just adding here few point from fedora link. Detailed description NetworkManager's existing support for bond interfaces covers a limited number of use-cases and can conflict with existing bonding configurations created by tools like libvirt. The purpose of this Fedora feature is to implement more flexible bonding infrastructure in NetworkManager to support an expanded number of use-cases and to be more cooperative with other users of bonding. Support will be added to NetworkManager to detect the existing configuration of a bond interface and its slaves and to seamless "take over" that connection without disrupting it. Even if the existing configuration is not backed by ifcfg files on-disk, NetworkManager will leave that configuration on the interface unless told to change it by the user via GUI or CLI tools. Additional bond interface configuration will be added to expand the use-cases and hardware that NetworkManager can configure (eg primary, use_carrier, xmit_hash_policy, etc). Given that libvirt is the way we proceed for network management in guest. My question here adding to Suresh is do we need to really warn the user about other tools like Network Manager? Tomorrow there can be other tools like cockpit , x , y which do the same task may not be completely. Then in that case we keep updating our warning? I feel we should restrict ourselves to kimchi/ginger and make sure the network management functionality we are implementing are in sync and do not disturb other tools. We should keep reading the configurations as long as they are standard irrespective of which tool is used for configuring. If we have write permissions we can very well modify those interfaces. If configurations are not valid we ignore them. ======================================================= Thanks, Abhiram Kulkarni, Staff Software Engineer, Z Firmware Development, IBM India Systems & Technology Lab, Bangalore, India. Phone: +91 80 28063288 “Be who you are and say what you feel, because those who mind don't matter, and those who matter don't mind.” ======================================================= From: Daniel Henrique Barboza <dhbarboza82@gmail.com> To: kimchi-devel@ovirt.org Date: 09/01/2015 06:39 PM Subject: Re: [Kimchi-devel] [RFC] Issue #650 - Kimchi & Network Manager Sent by: kimchi-devel-bounces@ovirt.org On 09/01/2015 03:02 AM, Suresh Babu Angadi wrote:
Are we advising end user to block Network Manager permanently?
No. We are advising the user to exercise caution with NetworkManager in these scenarios. It is a known fact that NetworkManager started support native bridge and bonding only in F20*. This Kimchi feature must be supported on older distros such as RHEL 7.1 that has older NetworkManager versions that doesn't have this native support. This is why we have this warning. The user can proceed with the operation with NetworkManager on, but he's on his own. * https://docs.fedoraproject.org/en-US/Fedora/20/html/Release_Notes/sect-Relea... _______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (4)
-
Abhiram Kulkarni -
Daniel Henrique Barboza -
Jose Ricardo Ziviani -
Suresh Babu Angadi