[Openstack] Whole sections of ml2_conf.ini being ignored?

Tyler Bishop tyler.bishop at beyondhosting.net
Mon Feb 22 13:45:12 UTC 2016


I highly recommend using the correct config files vs the symlink configuration. 

I think the guide should be updated to reflect the config based on the driver instead... when you run yum update ect it will break neutron until you re-edit the systemd files. 




From: "Matt Kassawara" <mkassawara at gmail.com> 
To: "Mark Hayden" <mhayden at coalesco.ca> 
Cc: openstack at lists.openstack.org 
Sent: Friday, February 19, 2016 7:34:23 PM 
Subject: Re: [Openstack] Whole sections of ml2_conf.ini being ignored? 

I managed to do the backport today, so you should see the new version merge into the Liberty version in the next few days. 

On Fri, Feb 19, 2016 at 10:38 AM, Mark Hayden < mhayden at coalesco.ca > wrote: 




Thanks for the quick help. I confirmed that the debian packaged install is set up this new way and moved the settings to the new location and finally made some progress. After clearing out the stuck "binding failed" from the database all the ports bind and my VM creates with a NIC and I can assign fixed and floating IPs. 

Now onto the next challenge: I can ping the virtual router (even from the internet on its public port!) but cannot reach the running instance on either IP (tried all the namespaces with ip netns exec... with both IPs but nothing). But I will create a new thread here unless someone has a quick answer. 
On 19 Feb 2016 09:00, Matt Kassawara < mkassawara at gmail.com > wrote: 

BQ_BEGIN

Looks like we (docs) never backported those fixes to the Liberty version of the guide. For some reason, the patch does not merge cleanly so I'm not sure when I'll get to it. 

On Thu, Feb 18, 2016 at 11:08 PM, Matt Kassawara < mkassawara at gmail.com > wrote: 

BQ_BEGIN

In Liberty, the L2 agent configuration moves from ml2_conf.ini to openvswitch_agent.ini for OVS and linuxbridge_agent.ini for Linux bridge. 

On Thu, Feb 18, 2016 at 10:51 PM, Mark Hayden < mark at haydensplace.com > wrote: 

BQ_BEGIN



Hi, 

I have recently installed a small openstack setup using the Liberty release (from Debian Sid packaging). I have gotten as far as setting up a controller/network and a compute node with keystone, glance, cinder and nova services, but have gotten stuck trying to set up a DVR configuration of Neutron/openvswitch. 

I had an early OpenStack setup a few years ago (Essex release) but so much has changed from that "primitive" system with nova-network that I am pretty much a novice, but I am particulatly interested in the DVR setup to eliminate the dependency on a single network node for future expansion. However I have spent a few days not making no progress at all. 

I have tried to follow the relevant guide at http://docs.openstack.org/liberty/networking-guide/scenario-dvr-ovs.html as close as possible but I have not been able to get anything to work. All my ports come up dead (DOWN state, and tagged 4095 in ovs-vsctl) when I set up the virtual router and I cannot launch any instances as they fail at the network port binding stage. 

In the nova-compute.log: 

2016-02-17 19:01:51.160 2556 ERROR nova.compute.manager [instance: 848c9525-3f48-4747-bbf1-d0d8bf52697b] PortBindingFailed: Binding failed for port bf1cde62-7ac6-47a8-8fb9-85ec524d02bd, please check neutron logs for more information. 

In neutron-server.log: 

2016-02-17 19:01:50.669 3224 ERROR neutron.plugins.ml2.managers [req-e6f1dbbd-d26c-456a-af6a-604c905dc194 b1ce670ebde640b0a0b159f01b18c04e ffbdd9d45cf84de0a204acfd0344ee6b - - -] Failed to bind port bf1cde62-7ac6-47a8-8fb9-85ec524d02bd on host hostserver-0001 

In neutron-openvswitch-agent.log: 

2016-02-17 19:01:56.894 8021 INFO neutron.agent.common.ovs_lib [req-08c30666-e891-46ca-8200-be3d22285767 - - - - -] Port bf1cde62-7ac6-47a8-8fb9-85ec524d02bd not present in bridge br-int 

2016-02-17 19:01:56.894 8021 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-08c30666-e891-46ca-8200-be3d22285767 - - - - -] port_unbound(): net_uuid None not in local_vlan_map 

I have tried using VXLAN as shown in the guide as well as VLAN but both do the same thing. However this seems to be more than a problem with the settings in the configuration files. This was revealed when I turned on debug level logging. 

For some reason no matter what settings I try in ml2_conf.ini most of them are ignored--it doesn't matter how many services I stop and start or even rebooting the entire system (even completely wiping out the database and starting over with network config), ALL the settings in the [ml2] section and all the [ml2_type_*] sections are ignored and a set of default values are used. The real sticking point seems to be that mechanism_drivers is always an empty list and tenant_network_types is always just ['local']. As such nova refuses to start any instances on the networks I set up. 

Has anybody else seen this behaviour? For what it's worth here is what I currently have in my ml2_conf.ini file: 





[ml2] 
type_drivers = flat,vlan,gre,vxlan 
tenant_network_types = vlan,gre,vxlan 
mechanism_drivers = openvswitch,l2population 

[ml2_type_flat] 
flat_networks = public 

[ml2_type_vlan] 
network_vlan_ranges = vlans:3:63 

[ml2_type_gre] 
tunnel_id_ranges = 1000:1999 

[ml2_type_vxlan] 
vni_ranges = 2000:2999 
vxlan_group = 239.1.1.1 

[ovs] 
local_ip = 10.37..3.254 
bridge_mappings = public:br-out,vlans:br-ex 

[agent] 
l2_population = True 
tunnel_types = vxlan,gre 
enable_distributed_routing = True 
arp_responder = True 

[securitygroup] 
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver 
enable_security_group = True 
enable_ipset = True 



and here is a sample of what appears in my logs: 

In neutron-server.log 

2016-02-18 11:37:12.353 13857 DEBUG oslo_service.service [-] ml2_type_flat.flat_networks = [] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.353 13857 DEBUG oslo_service.service [-] ml2.extension_drivers = [] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.353 13857 DEBUG oslo_service.service [-] ml2.external_network_type = None log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.354 13857 DEBUG oslo_service.service [-] ml2.mechanism_drivers = [] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.354 13857 DEBUG oslo_service.service [-] ml2..path_mtu = 0 log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.355 13857 DEBUG oslo_service.service [-] ml2.physical_network_mtus = [] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.355 13857 DEBUG oslo_service.service [-] ml2.segment_mtu = 0 log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.355 13857 DEBUG oslo_service.service [-] ml2.tenant_network_types = ['local'] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.356 13857 DEBUG oslo_service.service [-] ml2.type_drivers = ['local', 'flat', 'vlan', 'gre', 'vxlan', 'geneve'] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.356 13857 DEBUG oslo_service.service [-] oslo_concurrency.disable_process_locking = False log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.357 13857 DEBUG oslo_service.service [-] oslo_concurrency.lock_path = /var/lib/neutron/lock log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.357 13857 DEBUG oslo_service.service [-] ml2_type_geneve.max_header_size = 50 log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.358 13857 DEBUG oslo_service.service [-] ml2_type_geneve.vni_ranges = [] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg..py:2233 
2016-02-18 11:37:12.358 13857 DEBUG oslo_service.service [-] ml2_type_vxlan.vni_ranges = [] log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 
2016-02-18 11:37:12.358 13857 DEBUG oslo_service.service [-] ml2_type_vxlan.vxlan_group = None log_opt_values /usr/lib/python2.7/dist-packages/oslo_config/cfg.py:2233 


and also during init in same log file: 

2016-02-17 20:49:20.683 20500 INFO neutron.plugins.ml2.managers [-] Configured type driver names: ['local', 'flat', 'vlan', 'gre', 'vxlan', 'geneve'] 
2016-02-17 20:49:20.687 20500 INFO neutron.plugins.ml2.drivers.type_flat [-] Allowable flat physical_network names: [] 
2016-02-17 20:49:20.696 20500 INFO neutron.plugins.ml2.drivers.type_vlan [-] Network VLAN ranges: {} 
2016-02-17 20:49:20.702 20500 INFO neutron.plugins.ml2.driverstype_local [-] ML2 LocalTypeDriver initialization complete 
2016-02-17 20:49:20.707 20500 INFO neutron.plugins.ml2.managers [-] Loaded type driver names: ['flat', 'geneve', 'vlan', 'gre', 'local', 'vxlan'] 
2016-02-17 20:49:20.708 20500 INFO neutron.plugins.ml2.managers [-] Registered types: ['flat', 'geneve', 'vlan', 'gre', 'local', 'vxlan'] 
2016-02-17 20:49:20.708 20500 INFO neutron.plugins.ml2.managers [-] Tenant network_types: ['local'] 
2016-02-17 20:49:20.709 20500 INFO neutron.plugins.ml2.managers [-] Configured extension driver names: [] 
2016-02-17 20:49:20.710 20500 INFO neutron.plugins.ml2.managers [-] Loaded extension driver names: [] 
2016-02-17 20:49:20.710 20500 INFO neutronplugins.ml2.managers [-] Registered extension drivers: [] 
2016-02-17 20:49:20.710 20500 INFO neutron.plugins.ml2.managers [-] Configured mechanism driver names: [] 
2016-02-17 20:49:20.711 20500 INFO neutronplugins.ml2.managers [-] Loaded mechanism driver names: [] 
2016-02-17 20:49:20.712 20500 INFO neutron.plugins..ml2.managers [-] Registered mechanism drivers: [] 
2016-02-17 20:49:20.722 20500 WARNING oslo_config.cfg [-] Option "username" from group "nova" is deprecated. Use option "user-name" from group "nova". 
2016-02-17 20:49:20.821 20500 INFO neutron.plugins..ml2.managers [-] Initializing driver for type 'flat' 
2016-02-17 20:49:20.822 20500 INFO neutron.plugins.ml2.drivers.type_flat [-] ML2 FlatTypeDriver initialization complete 
2016-02-17 20:49:20.822 20500 INFO neutron.plugins.ml2.managers [-] Initializing driver for type 'geneve' 
2016-02-17 20:49:20.823 20500 INFO neutron.plugins.ml2.drivers.type_tunnel [-] geneve ID ranges: [] 
2016-02-17 20:49:21008 20500 INFO neutron.plugins.ml2.managers [-] Initializing driver for type 'vlan' 
2016-02-17 20:49:21.012 20500 INFO neutron.plugins.ml2.drivers.type_vlan [-] VlanTypeDriver initialization complete 
2016-02-17 20:49:21.012 20500 INFO neutron.plugins.ml2.managers [-] Initializing driver for type 'gre' 
2016-02-17 20:49:21.013 20500 INFO neutron.plugins.ml2.drivers.type_tunnel [-] gre ID ranges: [] 
2016-02-17 20:49:21.016 20500 INFO neutron.plugins.ml2.managers [-] Initializing driver for type 'local' 
2016-02-17 20:49:21.016 20500 INFO neutron.plugins.ml2.managers [-] Initializing driver for type 'vxlan' 
2016-02-17 20:49:21.017 20500 INFO neutron.plugins.ml2.drivers.type_tunnel [-] vxlan ID ranges: [] 
2016-02-17 20:49:21.021 20500 INFO neutron.plugins.ml2.plugin [-] Modular L2 Plugin initialization complete 


examining the actual code it appears my settings are always ignored and non-functional defaults are used. 

What am I missing? The problem persisted even after wiping the netowrk config and database and set up from scratch. 

If anyone has an idea let me know--I can provide additional info if required. 

Thanks! 

_______________________________________________ 
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
Post to : openstack at lists.openstack.org 
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 






BQ_END



BQ_END


BQ_END



_______________________________________________ 
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
Post to : openstack at lists.openstack.org 
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160222/07a0e7dc/attachment.html>


More information about the Openstack mailing list