Errors when installing neutron #161

Closed
talcum opened this Issue Mar 4, 2015 · 8 comments

2 participants

@talcum

Hi,

I've attempted both allinone and multinode but keep getting Errors relating to Neutron when puppet attempts to apply the catalog, resulting in a broken install. A couple of quick points to give more context and then I'll share the errors.

*environment is Openstack Icehouse: attempting to deploy onto instances within a test tenant.
*using ubuntu 14.04 uec images
*2 network setup: API and External networks are network 'A', and management and data are combined on network 'B'.

Can also say that I expected the network node install to fail since I saw a Neutron related error during the control install, but still thought I should see it through in case of false alarm.

Since I haven't yet successfully deployed openstack with this module yet, I can't discount the possibility that I'm simply making a configuration mistake, though I have double and triple checked my hiera yaml file and couldn't find any problems.

Whether this is a bug or simply a configuration mistake, any help is appreciated!

Errors during control node install
Error: /Stage[main]/Neutron::Plugins::Ml2/File_line[/etc/default/neutron-server:NEUTRON_PLUGIN_CONFIG]: Could not evaluate: No such file or directory - /etc/default/neutron-server

Info: Concat[/etc/swift/proxy-server.conf]: Scheduling refresh of Service[swift-proxy]
Error: Could not start Service[swift-proxy]: Execution of '/sbin/start swift-proxy' returned 1: start: Job failed to start
Wrapped exception:
Execution of '/sbin/start swift-proxy' returned 1: start: Job failed to start
Error: /Stage[main]/Swift::Proxy/Service[swift-proxy]/ensure: change from stopped to running failed: Could not start Service[swift-proxy]: Execution of '/sbin/start swift-proxy' returned 1: start: Job failed to start

Notice: /Stage[main]/Neutron::Server/Service[neutron-server]: Dependency File_line[/etc/default/neutron-server:NEUTRON_PLUGIN_CONFIG] has failures: true
Warning: /Stage[main]/Neutron::Server/Service[neutron-server]: Skipping because of failed dependencies

Errors during network node install

Error: /Stage[main]/Neutron::Plugins::Ml2/File_line[/etc/default/neutron-server:NEUTRON_PLUGIN_CONFIG]: Could not evaluate: No such file or directory - /etc/default/neutron-server

...and then I completely lose network after it attempts this:

Notice: /Stage[main]/Neutron::Agents::Ml2::Ovs/Vs_bridge[br-int]/ensure: created

looking on the system console, I can see that after this step it attempts to install various packages and utterly fails since there is no network connectivity...

@talcum

realized I should probably share my common.yaml file. I added a few comment lines to help me keep all the IP addresses straight, but otherwise it follows the structure of the original example file.

common.yaml
openstack::region: 'openstack'

######## Networks
openstack::network::api: '192.168.11.0/24'
openstack::network::external: '192.168.11.0/24'
openstack::network::management: '192.168.12.0/24'
openstack::network::data: '192.168.12.0/24'

openstack::network::external::ippool::start: 192.168.11.150
openstack::network::external::ippool:🔚 192.168.11.200
openstack::network::external::gateway: 192.168.11.1
openstack::network::external::dns: 130.239.1.90

######## Private Neutron Network

openstack::network::neutron::private: '10.0.0.0/24'

######## Fixed IPs (controllers)

openstack::controller::address::api: '192.168.11.28'
openstack::controller::address::management: '192.168.12.18'
openstack::storage::address::api: '192.168.11.32'
openstack::storage::address::management: '192.168.12.22'

######## Database

openstack::mysql::root_password: 'spam-gak'
openstack::mysql::service_password: 'fuva-wax'

#last parameter should specify the management network
openstack::mysql::allowed_hosts: ['localhost', '127.0.0.1', '192.168.12.%']

openstack::mysql::keystone::user: 'keystone'
openstack::mysql::keystone::pass: 'fuva-wax'

openstack::mysql::cinder::user: 'cinder'
openstack::mysql::cinder::pass: 'fuva-wax'

openstack::mysql::glance::user: 'glance'
openstack::mysql::glance::pass: 'fuva-wax'

#should be same address as storage::address::management
openstack::glance::api_servers: ['192.168.12.22:9292']

openstack::mysql::nova::user: 'nova'
openstack::mysql::nova::pass: 'fuva-wax'

openstack::mysql::neutron::user: 'neutron'
openstack::mysql::neutron::pass: 'fuva-wax'

openstack::mysql::heat::user: 'heat'
openstack::mysql::heat::pass: 'fuva-wax'

######## RabbitMQ

openstack::rabbitmq::user: 'openstack'
openstack::rabbitmq::password: 'pose-vix'

#should be same as controller::address::management
openstack::rabbitmq::hosts: ['192.168.12.18:5672']

######## Keystone

openstack::keystone::admin_token: 'sosp-kyl'
openstack::keystone::admin_email: 'email@server.com'
openstack::keystone::admin_password: 'fyby-tet'

openstack::keystone::tenants:
"test":
description: "Test tenant"
"test2":
description: "Test tenant"

openstack::keystone::users:
"test":
password: "abc123"
tenant: "test"
email: "test@example.com"
admin: true
"demo":
password: "abc123"
tenant: "test"
email: "demo@example.com"
admin: false
"demo2":
password: "abc123"
tenant: "test2"
email: "demo@example.com"
admin: false

######## Glance

openstack::glance::password: 'na-mu-va'

######## Cinder

openstack::cinder::password: 'zi-co-se'
openstack::cinder::volume_size: '8G'

######## Swift

openstack::swift::password: 'dexc-flo'
openstack::swift::hash_suffix: 'pop-bang'

######## Nova

openstack::nova::libvirt_type: 'kvm'
openstack::nova::password: 'quuk-paj'

######## Neutron

openstack::neutron::password: 'whi-rtuz'
openstack::neutron::shared_secret: 'by-sa-bo'
openstack::neutron::core_plugin: 'ml2'
openstack::neutron::service_plugins: ['router', 'firewall', 'lbaas', 'vpnaas', 'metering']

######## Ceilometer
#should be same as controller::address::management
openstack::ceilometer::address::management: '192.168.12.18'

openstack::ceilometer::mongo::username: 'mongo'
openstack::ceilometer::mongo::password: 'mongosecretkey123'
openstack::ceilometer::password: 'whi-truz'
openstack::ceilometer::meteringsecret: 'ceilometersecretkey'

######## Heat
openstack::heat::password: 'zap-bang'
openstack::heat::encryption_key: 'heatsecretkey123'

######## Horizon

openstack::horizon::secret_key: 'whu-ghuk'

######## Tempest

openstack::tempest::configure_images : true
openstack::tempest::image_name : 'Cirros'
openstack::tempest::image_name_alt : 'Cirros'
openstack::tempest::username : 'demo'
openstack::tempest::username_alt : 'demo2'
openstack::tempest::username_admin : 'test'
openstack::tempest::configure_network : true
openstack::tempest::public_network_name : 'public'
openstack::tempest::cinder_available : true
openstack::tempest::glance_available : true
openstack::tempest::horizon_available : true
openstack::tempest::nova_available : true
openstack::tempest::neutron_available : true
openstack::tempest::heat_available : false
openstack::tempest::swift_available : false

######## Log levels
openstack::verbose: 'True'
openstack::debug: 'True'

@cmurphy

I'm not able to reproduce this on a generic Ubuntu image, though admittedly I'm not able to reproduce your exact environment.

The neutron module doesn't manage the /etc/default/neutron-server file. It is supposed to be provided by the neutron-server package:

# dpkg -S /etc/default/neutron-server
neutron-server: /etc/default/neutron-server

This package should be installed before the file_line resources attempt to manipulate the file. Can you verify whether the neutron-server package is installed? Are you perhaps using packages other than those provided by UCA?

@talcum

Thanks for taking a look at this.

yes the neutron-server pkg is installed and per the suggestion of Robert in the disussion here:

https://groups.google.com/a/puppetlabs.com/forum/#!topic/puppet-openstack/jp9x0l8YsbM

I had done 'touch /etc/default/neutron-server' to get around this error. I can now see that the package has since added this content to the file:

NEUTRON_PLUGIN_CONFIG=/etc/neutron/plugin.ini

but as I mention in the other conversation, the installation is still falling over when it attempts to create a bridge.

Also, I haven't changed any settings concerning which packages are being pulled in, so the modules should be setting up and pulling in the default packages as they ought to. The content of :

/etc/apt/sources.list.d/ubuntu-cloud-archive.list/ubuntu-cloud-archive.list

is:

#file generated by puppet

ubuntu-cloud-archive

deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/juno main
deb-src http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/juno main

@talcum

@cmurphy - In what environment you are successfully deploying using the Ubuntu trusty cloud image for the base OS?

@cmurphy

@talcum I usually use puppetlabs' trusty image for vagrant [https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-puppet]. I ran into the br-tun issue but not the /etc/default/neutron-server issue.

For this I also tried using an ubuntu cloud image [https://atlas.hashicorp.com/urban/boxes/trusty64-node]. This one had strange issues with rabbitmq but none of the issues you described.

Could you paste the entire output of a puppet run on the control node (starting from a clean node), as well as your site.pp or enc configuration? http://paste.openstack.org/

@talcum

Since you hit the br-tun issue as well, how did you work around it?

here is the output from a puppet catalog run for an allinone, this time within virtualbox:

part 1 -
http://paste.openstack.org/show/192888/

part 2 -
http://paste.openstack.org/show/192891/

Here is the site.pp, hiera.yaml and allinone.yaml:
http://paste.openstack.org/show/192894/

@cmurphy

@talcum I'm not sure what changed, but I hit your neutron-server issue. It's an ordering issue in the neutron module, I've sent a patch upstream: https://review.openstack.org/#/c/170309/

The swift-proxy issue is because the swift-proxy service needs to collect exported resources before it can start. I'd like to change the controller role to not need to deploy swift, but that will probably have to wait for the next release.

I haven't run into the br-tun issue again, so I'm not sure how to work around it. Are you still having an issue with it?

@cmurphy

The neutron-server patch was committed.

The swift-proxy issue will hopefully be fixed in a refactor of this module later on.

I'm still not seeing the br-tun issue, but if you still are I would suspect an issue in the neutron module itself, as this module does not create that interface directly. I would report it on launchpad: https://bugs.launchpad.net/puppet-neutron

@cmurphy cmurphy closed this Apr 27, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment