Created attachment 917371 [details] /var/log/neutron/server.log from the neutron controller. Rubygem-Staypuft: Neutron deployment gets stuck on 20%. Environment: rhel-osp-installer-0.1.0-2.el6ost.noarch ruby193-rubygem-staypuft-0.1.11-1.el6ost.noarch openstack-foreman-installer-2.0.13-1.el6ost.noarch ruby193-rubygem-foreman_openstack_simplify-0.0.6-7.el6ost.noarch openstack-puppet-modules-2014.1-18.1.el6ost.noarch Steps to reproduce: 1. Install rhel-osp-installer 2. Create a neutron deployment with 3 hosts (1 controller +1 networker +1 compute) 3. Set the "Tenant Netwotk Type" to "VLAN Segmentation". 4. Set the "Tenant (VM data) VLAN Ranges" to "int_vlan_range:216:217,int_vlan_range:192:192" 5. Start the deployment. Results: Neutron deployment gets stuck on 20%.In the "more details" page - I see that it's stuck on 60% installing the Neutron controller. Manually running the puppet agent on the Neutron controller - I see this: Error: Could not start Service[neutron-server]: Execution of '/sbin/service neutron-server start' returned 1: Error: /Stage[main]/Neutron::Server/Service[neutron-server]/ensure: change from stopped to running failed: Could not start Service[neutron-server]: Execution of '/sbin/service neutron-server start' returned 1: Expected result: Deployment completed 100%.
The yaml output for the controller is in the link: http://pastebin.test.redhat.com/221069
I'd suggest for debugging purposes adding "vlan" to the ml2_type_drivers parameter and retrying puppet on the controller.
Changed it from ["vxlan","flat"] to ["vxlan","flat","vlan"] and reran puppet on the node. Still fails with the same error. The changes/errors are below. Info: Applying configuration version '1405121948' Notice: /Stage[main]/Quickstack::Swift::Proxy/Quickstack::Rsync::Simple[swift_server]/Exec[restart-xinetd-swift_server]/returns: executed successfully Notice: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_user_role[ceilometer@services]/roles: roles changed ['ResellerAdmin', 'admin'] to 'admin ResellerAdmin' Notice: /Stage[main]/Neutron::Plugins::Ml2/Neutron_plugin_ml2[ml2/type_drivers]/value: value changed 'vxlan,flat' to 'vxlan,flat,vlan' Info: /Stage[main]/Neutron::Plugins::Ml2/Neutron_plugin_ml2[ml2/type_drivers]: Scheduling refresh of Service[neutron-server] Notice: /Stage[main]/Neutron::Plugins::Ml2/Neutron::Plugins::Ml2::Driver[vlan]/Neutron_plugin_ml2[ml2_type_vlan/network_vlan_ranges]/ensure: created Info: /Stage[main]/Neutron::Plugins::Ml2/Neutron::Plugins::Ml2::Driver[vlan]/Neutron_plugin_ml2[ml2_type_vlan/network_vlan_ranges]: Scheduling refresh of Service[neutron-server] Notice: /Stage[main]/Neutron::Server::Notifications/Nova_admin_tenant_id_setter[nova_admin_tenant_id]/ensure: created Notice: /Stage[main]/Quickstack::Neutron::Controller/Exec[neutron-db-manage upgrade]/returns: executed successfully Error: Could not start Service[neutron-server]: Execution of '/sbin/service neutron-server start' returned 1: Error: /Stage[main]/Neutron::Server/Service[neutron-server]/ensure: change from stopped to running failed: Could not start Service[neutron-server]: Execution of '/sbin/service neutron-server start' returned 1: Notice: /Stage[main]/Neutron::Server/Service[neutron-server]: Triggered 'refresh' from 2 events Notice: Finished catalog run in 55.09 seconds
OK, looking at your log posted above as well as the yaml output from foreman, it looks to me like there error is @ line 95/96: ml2_type_drivers: - vxlan The output in the log says: 2014-07-11 15:24:32.639 19494 INFO neutron.plugins.ml2.managers [-] Registered types: ['flat', 'vxlan'] 2014-07-11 15:24:32.640 19494 ERROR neutron.plugins.ml2.managers [-] No type driver for tenant network_type: vlan. Service terminated! So you probably just need to set vlan instead of vxlan in your ml2_type_drivers (you have it only in ml2_tenant_network_types currently)
Patch posted: https://github.com/redhat-openstack/astapor/pull/310
Merged
Verified: rhel-osp-installer-0.1.6-5.el6ost.noarch the deployment completed 100% without any intervention. Note: At the time I was also selecting a vlan range that was too big, and might have used the wrong interfaces for tenant/external networks.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1003.html