rcbops / chef-cookbooks Goto Github PK

Forum Post: https://privatecloudforums.rackspace.com/viewtopic.php?f=4&t=351

Mysql is not starting due to the following error: InnoDB: Error: ib_logfiles are too small for innodb_thread_concurrency 64.

Fix is to lower the concurrency to a lower value.

The slow log being enabled is causing issues with an alter table statement that was trying to be replicated.

Using the "Basic Server" installation type in RHEL 6.2, qpid is installed and run on the same port rabbitmq is configured to run on. Because of this, the chef installation fails when trying to start rabbitmq.

To move past this step, I did the following:
yum remove -y qpid-*

This removed the following packages:
qpid-cpp-client
qpid-cpp-client-ssl
qpid-cpp-server
qpid-cpp-server-ssl
qpid-qmf

Plus the following for dependencies:
matahari
matahari-agent-lib
matahari-broker
matahari-host
matahari-network
matahari-service
matahari-sysconfig

Once these packages are removed rabbitmq starts.

not issue, just want to know how to make some no-need-public service use internal network, for instance, I have two network interface, first one have public IP and second one have private IP, I want some service use private ip address like mysql, novnc, for security reason, just give me some tips and I will finger everything else out, thanks

Request has been made to allow overcommit cpu/ram.

I believe the flags are --max_cores and --max_gigabytes which i believe should be configurable at the node level.

The recipes for keystone,etc are tying to connect to mysql as 'root'@'10.0.2.15' (for example) however there is no grant for root @ ipaddress; there is only root @ localhost and 127.0.0.1.

Set allow_remote_root = true in mysql attribute to fix this.

I'll be adding a Pull request for this issue.

OpenStack queries don't use indexes very well and enabling this option causes a very large slow query log file.

We saw a 45GB in 2 days without much load on the environment.

We should disable this variable or allow it to be enabled/disabled via an override.

Ryan

• Horizon CSS changes
• Nova novnc console bugfix
• Osops-utils update to use Ubuntu cloud archive

I found a bug in the block migration test. The detail info is given as following.

1. 364025-aio: AIO installation of Alamo v2 generated using alamo builder built by Jacob.
2. 364026-compute: Compute node installation of Alamo v2 generated using alamo builder built by Jacob.
3. Create an 512 MB cirros instance on 364025-aio.
4. nova live-migration --block_migrate 364026-compute
5. System does not return an error. nova boot shows it is in migrating.
6. When the status turns to ACTIVE, nova show . It is still in 364025-aio.
7. Check the actual instance file. They are in 364025-aio instead of 364026-compute.
8. Check /var/log/nova/nova-scheduler.log, nova-network.log, nova-compute.log, no error message.
9. Create another vm and migrate, works.

I have sent to you the sosreport before and after the failure.

1. Migrate a vm from aio to compute node.
2. Nova list shows MIGRATING status.
3. Instance directory has actually been moved to the compute node. Can ping and ssh to the vm.

Could not reproduce.

selinux will cause some recipe fail on centos or redhat, one I know now is rsyslog

http://lists.fedoraproject.org/pipermail/cloud/2012-November/001848.html

we need to stop using the side repo for folsom packages

Monitoring my Alamo v.2 ISO post-installer logs & it's failing to complete because it's unable to locate the appropriate resources online:
[Tue, 27 Nov 2012 21:39:59 -0500] [72] Generating chef-client keys
[Tue, 27 Nov 2012 21:40:02 -0500] [80] Downloading cookbooks
/root /root
error: The requested URL returned error: 403 while accessing http://github.com/rcbops/chef-cookbooks/info/refs
fatal: HTTP request failed
error: The requested URL returned error: 403 while accessing http://github.com/rcbops/chef-cookbooks/info/refs
fatal: HTTP request failed

This is because http://github.com/rcbops/chef-cookbooks/info/ no longer exists

introduction of minitests has a broken symlink and causes the cookbook upload to fail on the iso

There is a problem where the nova.conf has the wrong values for public_interface and fixed_range that causes instances to be able to do any outbound traffic. The values get set to the defaults of eth0 and 192.168.100.0/24, respectively. Once I plug the correct values for the machine's configuration, outbound traffic starts working.

When enabling swift storage in image service by executing

knife exec -E '@e=Chef::Environment.load("rpcs"); a=@e.
override_attributes;
a["glance"].merge!({"api" => {"default_store" => "swift"}});
@e.override_attributes(a); @e.save'

chef returns an error saying "Could not find recipe -volume for cookbook nova". Sprint branch is used.

so far I just see the newly create rsyslog.conf not work bacause selinux, disable selinux may be easy( I don't know how to write selinux policy)

I didn't see an issue already created for volumes.

I've going through the private cloud setup and I see that your
openssh cookbook allows for all the items to be configured... which is
good. Except by default you drop a 3 line config that effectively
disables sftp-server.

Would be really nice if you weren't just replacing the file with a
populated template, specially since your not configuring anything as I
believe those 3 entries are defaults in most major distributions.

Ideally, I'd suggest doing the same interface but using Augeas on the
backend, but I haven't tried that with chef. The augeasprovider for
Puppet makes this very nice. Here is the doc for reference:
https://github.com/raphink/augeasproviders/blob/master/docs/examples/sshd_config.md

Have you considered using librarian-chef instead of git submodules?

nova-xvpvncproxy and nova-vncproxy cannot be installed at the same time. we need a flag to define which vnc tool we want to use and default to nova-vncproxy

debian package to install:
novnc

steps to reproduce
clean chef run
apt-get install novnc

nova-xvpvncproxy is uninstalled and nova-novncproxy is installed

I've been following "rackspace-private-cloud-swift-install.pdf" guide (Until page 14). I set up everything up so far without error and created my rings. I tried to re-run the chef-client to distribute the ring but there were errors on proxy and storage nodes starting particular services

The proxy node encountered the following fatal error:
Error executing action start on resource 'service[swift-proxy]'

/var/log/upstart/swift-proxy.log:

Starting proxy-server...(/etc/swift/proxy-server.conf)
Traceback (most recent call last):
File "/usr/bin/swift-proxy-server", line 22, in
run_wsgi(conf_file, 'proxy-server', default_port=8080, *_options)
File "/usr/lib/python2.7/dist-packages/swift/common/wsgi.py", line 138, in run_wsgi
loadapp('config:%s' % conf_file, global_conf={'log_name': log_name})
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in loadapp
return loadobj(APP, uri, name=name, *_kw)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in loadobj
return context.create()
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
return self.object_type.invoke(self)
File "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 207, in invoke
app = filter(app)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/auth_token.py", line 815, in auth_filter
return AuthProtocol(app, conf)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/auth_token.py", line 210, in init
self.signing_dirname = '%s/keystone-signing' % os.environ['HOME']
File "/usr/lib/python2.7/UserDict.py", line 23, in getitem
raise KeyError(key)
KeyError: 'HOME'

The storage nodes encountered the following fatal error:
Error executing action start on resource 'service[swift-account-reaper]'

/var/log/upstart/swift-account-reaper.log:
Starting account-reaper...(/etc/swift/account-server.conf)
Traceback (most recent call last):
File "/usr/bin/swift-account-reaper", line 17, in
from swift.account.reaper import AccountReaper
File "/usr/lib/python2.7/dist-packages/swift/account/reaper.py", line 27, in
from swift.common.direct_client import ClientException,
File "/usr/lib/python2.7/dist-packages/swift/common/direct_client.py", line 29, in
from swiftclient import ClientException, json_loads
ImportError: No module named swiftclient

The replicator scripts are running but failing to do anything resulting in only one server having the images.

Hi guys,

Sorry this might be a non-issue again. I didn't find a place to send questions. I'll just put it here. Later if it turns out that this is not an issue, I'll remove it.

The problem I have is keystone version. It seems the keystone.conf is already folsom, however the source code for keystone is essex. When I install everything from a fresh start using chef-cookbooks, keystone failed complaining no module for stats. It turns out that stats is provided by keystone, and it's there contrib/stats in folsom, not in essex.

keystone.conf:
[filter:stats_monitoring]
paste.filter_factory = keystone.contrib.stats:StatsMiddleware.factory

The source code that the cookbook pulls doesn't have this module.

Thanks,
Xin

Hi,

I'm new to chef. This might not be a bug. But I thought it will be good if I post it here so that later people might find it useful.

During the installation of openstack, some keys need to be imported, as in chef-cookbooks/osops-utils/recipes/packages.rb

For some reason, even chef-client is run as root, the key import command is run as root for me. So the key is never imported, and a fatal error is thrown.

With the above I think the "apt-key" run needs to be "sudo apt-key". I'm new to ruby also... will changing run to run_or_sudo do the magic?

Thanks,
Xin

Hi guys,

I got the following error when working with Ruby 1.9.3, gems 1.8 and chef client 10.18.2. It seems to be an issue that has been resolved, but somehow reappear: https://github.com/rcbops-cookbooks/nova/issues/149

Thanks,
Xin

Generated at Fri Jan 25 09:32:55 -0800 2013
TypeError: dsh_group[nova](nova::nova-common line 89) had an error: TypeError: can't convert Hash into String
/var/chef/cache/cookbooks/dsh/providers/group.rb:148:in system' /var/chef/cache/cookbooks/dsh/providers/group.rb:148:inget_pubkey'
/var/chef/cache/cookbooks/dsh/providers/group.rb:85:in class_from_file' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/provider.rb:203:ininstance_eval'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/provider.rb:203:in action_join' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/provider.rb:119:insend'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/provider.rb:119:in run_action' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource.rb:597:inrun_action'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/runner.rb:49:in run_action' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/runner.rb:81:inconverge'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/runner.rb:81:in each' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/runner.rb:81:inconverge'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource_collection.rb:94:in execute_each_resource' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:incall'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in call_iterator_block' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:instep'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in iterate' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:ineach_with_index'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/resource_collection.rb:92:in execute_each_resource' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/runner.rb:80:inconverge'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/client.rb:378:in converge' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/client.rb:420:indo_run'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/client.rb:176:in run' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:140:inrun_chef_client'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/client.rb:274:in run_application' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/client.rb:267:inloop'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/client.rb:267:in run_application' /usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:72:inrun'
/usr/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/chef-client:26
/usr/bin/chef-client:23:in `load'
/usr/bin/chef-client:23

root@os-server1:/usr/lib/ruby# ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]

A new quota was implemented to resolve https://bugs.launchpad.net/bugs/1125468 on Fixed IPs. At current it is set to 10.

We need to set this to a reasonable value. nova.conf value is

quota_fixed_ips

I have a fresh Ubuntu 12.04.2 LTS install that I'm trying to setup OpenStack on. I'm using Chef and have assigned this particular node role[single-controller] and role[single-compute]. When I run chef-client, I'm getting:

[2013-03-12T19:47:10-04:00] ERROR: Can't find network management

================================================================================
Recipe Compile Error in /var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb
================================================================================

RuntimeError
------------
Can't find network management

Cookbook Trace:
---------------
  /var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:346:in `get_ip_for_net'
  /var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:151:in `get_bind_endpoint'
  /var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb:29:in `from_file'

Relevant File Content:
----------------------
/var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:

339:          node["osops_networks"]["mapping"].has_key?(network)
340:        network = node["osops_networks"]["mapping"][network]
341:      end
342:
343:      if not (node.has_key?("osops_networks") and node["osops_networks"].has_key?(network)) then
344:        error = "Can't find network #{network}"
345:        Chef::Log.error(error)
346>>       raise error
347:      end
348:
349:      net = IPAddr.new(node["osops_networks"][network])
350:      node["network"]["interfaces"].each do |interface|
351:        if interface[1].has_key?("addresses") then
352:          interface[1]["addresses"].each do |k,v|
353:            if v["family"] == "inet6" or (v["family"] == "inet" and v["prefixlen"] != "32") then
354:              addr=IPAddr.new(k)
355:              if net.include?(addr) then

[2013-03-12T19:47:10-04:00] ERROR: Running exception handlers
[2013-03-12T19:47:10-04:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2013-03-12T19:47:10-04:00] ERROR: Exception handlers complete
[2013-03-12T19:47:10-04:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2013-03-12T19:47:10-04:00] FATAL: RuntimeError: Can't find network management

I also have the full chef-client run.

I should mention that I'm not using this chef-cookbooks repo directly. I've installed all the opscode cookbooks (except RabbitMQ, using the one on GitHub because openstack needs a newer version) using knife cookbook site install and cped over the OpenStack cookbooks. I uploaded everything to the Chef server.

Thank you in advance.

🚨 Spoiler Alert 🚨

This is a bug in Nova, not the Chef cookbooks.

Issue

The bridge and NAT configurations for floating IP addresses are not migrated to the destination host after a confirmed resize.

Steps to reproduce

1. Build an instance
2. Assign a floating IP address to that instance
3. Resize the instance and confirm the resize
4. Try to access instance via floating IP, and/or check bridge/NAT rules on the source host.

Workaround

1. Disassociate the floating IP. nova remove-floating-ip <instance-uuid> <floating-ip>
2. Reassociate the floating IP on the new host. nova add-floating-ip <instance-uuid> <floating-ip>
3. Restart nova-network on the source host to remove the old bridge config and NAT rules. service nova-network restart

Affects

Folsom

Launchpad Bug

https://bugs.launchpad.net/nova/+bug/1053344

Hi, I am try to use this cookbooks to install openstack on centos 6.2, at the beggining I meet this odd problem

knife node run list add all.chef.com role[single-controller]
# returns
run_list:  recipe[roles]

role[allinone] can be added correctly, also, add role[single-controller] to ' works fine, it not chef-cookbooks 's problem, but I just want to know that if some thing I don't know yet about chef

BTW, I try to test this cookbook on centos6.2, any question will report here, if you don't mind

Forum post:
https://privatecloudforums.rackspace.com/viewtopic.php?f=4&t=366

Error:
Error executing action install on resource 'package[bitmap]'

The following packages were not found in the RHEL repositories:
xbitmaps-1.1.1-4.ram1.x86_64.rpm
bitmap-fonts-compat-0.3-15.el6.noarch.rpm
bitmap-miscfixed-fonts-0.3-15.el6.noarch.rpm
bitmap-fangsongti-fonts-0.3-15.el6.noarch.rpm
bitmap-console-fonts-0.3-15.el6.noarch.rpm

After installing the packages, the user was able to successfully run chef-client with the graphite role

Using the default redhat repositories, RHEL 6.2 has no package dnsmasq-utils available, and the cookbooks require it and thus fail.

Hi guys,

I think role[allinone] is missing the nova-api role, which is needed for retrieving metadata. I have included this additional role, and it seems the VM is able to download metadata.

Thanks,
Xin

this message in log

WARN: Missing gem 'right_aws'
INFO: Missing gem 'mysql'

which cookbook should I report to?

After assigning the role role[swift-object-server], role[swift-container-server], role[swift-account-server] to a machine the /etc/fstab file becomes clobbered and fails to boot.

Specifically:
"LABEL=cloudimg-rootfs / ext4 defaults 0 0" becomes
"LABEL=cloudimg-rootfs /ext4defaults00"

Looking at: chef-cookbooks/cookbooks/swift/providers/mounts.rb it appears this possibly could be causing it??? but I'm not sure.

Instance type "Ubuntu 12.04.1 Precise (cloudimg)"
Swift cookbook version: 1.0.12

In the file environments/example.json, the images to include are out of date and some of the data is missing from the glance attributes to support them. Per Joe, I removed all of the images from the example and instead used cirros and precise. With these changes the build continued.

I found a bug, which probably is an openstack bug.

1. 364026-aio node
2. 364217-compute node
3. nova boot --flavor 1 --image cirros-image Test
4. nova live-migration --block_migrate 871e24ab-fc79-4dc9-8071-7b5dc1b50cd0 364217-compute (assume the id is 871e24ab-fc79-4dc9-8071-7b5dc1b50cd0 and the instance landed on 364026-aio)
5. nova show Test | grep -e 'vm_state' -e 'ATTR:host' -e 'status'
6. nova live-migration --block_migrate 871e24ab-fc79-4dc9-8071-7b5dc1b50cd0 364026-aio
7. nova show Test | grep -e 'vm_state' -e 'ATTR:host' -e 'status'
8. Repeat step 4 - 7.

vm status changed from MIGRATING to ACTIVE, but sill in the node where it should be migrated from.

grep 'ERROR' nova-compute.log:

2012-11-02 10:24:13 ERROR nova.virt.libvirt.driver [-] [instance: 871e24ab-fc79-4dc9-8071-7b5dc1b50cd0] During wait destroy, instance disappeared.
2012-11-02 10:24:13 ERROR nova.openstack.common.rpc.amqp [-] Exception during message handling
2012-11-02 10:24:13 ERROR nova.openstack.common.rpc.common [-] Returning exception The supplied disk path (/var/lib/nova/instances/instance-00000003) already exists, it is expected not to exist. to caller
2012-11-02 10:24:13 ERROR nova.openstack.common.rpc.common [-] ['Traceback (most recent call last):\n', ' File "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line 275, in _process_data\n rval = self.proxy.dispatch(ctxt, version, method, *_args)\n', ' File "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py", line 145, in dispatch\n return getattr(proxyobj, method)(ctxt, *_kwargs)\n', ' File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2142, in pre_live_migration\n self.driver.pre_block_migration(context, instance, disk)\n', ' File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2556, in pre_block_migration\n raise exception.DestinationDiskExists(path=instance_dir)\n', 'DestinationDiskExists: The supplied disk path (/var/lib/nova/instances/instance-00000003) already exists, it is expected not to exist.\n']
2012-11-02 10:24:20 ERROR nova.virt.libvirt.driver [-] [instance: 871e24ab-fc79-4dc9-8071-7b5dc1b50cd0] During wait destroy, instance disappeared.

I'm getting further installing but I've now run an issue with the recipe not being able to log into the database. I've set up the example environment, is there anything else I should do? The chef run is below. Thank you!

2013-03-15T17:13:59-04:00] INFO: Processing ruby_block[cleanup insecure default mysql users] action create (mysql-openstack::server line 177)

================================================================================
Error executing action `create` on resource 'ruby_block[cleanup insecure default mysql users]'
================================================================================

Mysql::Error
------------
Access denied for user 'root'@'localhost' (using password: YES)

Cookbook Trace:
---------------
/var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb:187:in `new'
/var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb:187:in `block (2 levels) in from_file'

Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb

177: ruby_block "cleanup insecure default mysql users" do
178:   block do
179:     mysql_conn = Mysql.new(bind_ip, "root", node["mysql"]["server_root_password"])
180:     Chef::Log.info("Removing insecure default mysql users")
181:     mysql_conn.query("DELETE FROM mysql.user WHERE User=''")
182:     mysql_conn.query("DELETE FROM mysql.user WHERE Password=''")
183:     mysql_conn.query("DROP DATABASE IF EXISTS test")
184:     mysql_conn.query("FLUSH privileges")
185:   end
186:   only_if do
187:     mysql_conn = Mysql.new(bind_ip, "root", node["mysql"]["server_root_password"])
188:     exists = mysql_conn.query("SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'test'")
189:     exists.num_rows > 0
190:   end
191: end
192:

Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb:177:in `from_file'

ruby_block("cleanup insecure default mysql users") do
  action "create"
  retries 0
  retry_delay 2
  block_name "cleanup insecure default mysql users"
  cookbook_name "mysql-openstack"
  recipe_name "server"
  block #<Proc:0x000000033e8ea8@/var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb:178>
  only_if { #code block }
end

[2013-03-15T17:13:59-04:00] ERROR: Running exception handlers
[2013-03-15T17:13:59-04:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2013-03-15T17:13:59-04:00] ERROR: Exception handlers complete
[2013-03-15T17:13:59-04:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2013-03-15T17:13:59-04:00] FATAL: Mysql::Error: ruby_block[cleanup insecure default mysql users] (mysql-openstack::server line 177) had an error: Mysql::Error: Access denied for user 'root'@'localhost' (using password: YES)

Hello,

I'm using the cookbooks from the main branch. After adding the single-controller role to the run list of a freshly created ec2 instance running Ubuntu 11.10 - the chef-client there fails saying that keystone-manage could not connect to the database.
I've checked manually the passwords for all the [nova,keystone,glance,dash] users and none of them have the required passwords.

I've found that disabling the condition not_if in the keystone recipe fixes this problem.

Thanks!
Bogdan

PS: Also could you please provide some docs for exactly how to use the recipes? I'm understand the big picture of how chef runs but i'm sure that the jsons in the examples folders need to be used somehow. Thanks!

collectd breaks when replacing the active node by the standby node. Failed when running chef-client.

This is a feature request for the concept used in rcbops-cookbooks/cinder#12

We need the ability to send iSCSI traffic between cinder volume nodes to nova compute nodes over a dedicated interface. This interface may be different than the interface used for management purposes.

example
eth0 (all) - management & service/message queue communication
eth1 (compute nodes) - interface for fixed network (instance <-> communication)
eth2 (compute/cinder volume nodes) - 10G - dedicated block storage interface

With the latest sprint branch, chef bombs on the follow error:

[Tue, 24 Jul 2012 00:47:14 +0000] INFO: template[/etc/collectd/plugins/mysql.conf] sending restart action to servicecollectd
[Tue, 24 Jul 2012 00:47:14 +0000] INFO: Processing service[collectd] action restart (collectd::default line 98)
[Tue, 24 Jul 2012 00:48:15 +0000] ERROR: service[collectd](collectd::default line 98) has had an error
[Tue, 24 Jul 2012 00:48:15 +0000] ERROR: Running exception handlers
[Tue, 24 Jul 2012 00:48:31 +0000] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[Tue, 24 Jul 2012 00:48:31 +0000] ERROR: Exception handlers complete
[Tue, 24 Jul 2012 00:48:31 +0000] ERROR: Mixlib::ShellOut::ShellCommandFailed: service[collectd](collectd::default line 98) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /etc/init.d/collectd restart ----
STDOUT: Restarting statistics collection and monitoring daemon: collectd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
STDERR: configfile: stat (/etc/collectd/thresholds/*.conf) failed: No such file or directory

WARNING: collectd might still be running.
In large setups it might take some time to write all pending data to
the disk. You can adjust the waiting time in /etc/default/collect.
---- End output of /etc/init.d/collectd restart ----

I was able to get around this by testing with a dummy conf file but it still did not restart appropriately or in the way chef is expecting.

Hi guys,

I think the nova.conf.erb template file is incorrect. Currently with the template, it produces a nova.conf like below:

NETWORK

network_manager=nova.network.manager.FlatDHCPManagermulti_host=falsepublic_interface=eth0fixed_range=1.1.1.0/24dmz_cidr=1.1.1.0/24force_dhcp_release=truesend_arp_for_ha=trueauto_assign_floating_ip=falsedhcp_domain=novalocaldhcpbridge_flagfile=/etc/nova/nova.confdhcpbridge=/usr/bin/nova-dhcpbridgelibvirt_use_virtio_for_bridges=true

This is no space and line breaks. I have modified nova.conf.erb to

NETWORK

<% @network_options.each do |key,value| %>
<%=key%>=<%=value %>
<% end %>

And now it generates correct nova.conf

NETWORK

network_manager=nova.network.manager.FlatDHCPManager
multi_host=false
public_interface=eth0
fixed_range=1.1.1.0/24
dmz_cidr=1.1.1.0/24
force_dhcp_release=true
send_arp_for_ha=true
auto_assign_floating_ip=false
dhcp_domain=novalocal
dhcpbridge_flagfile=/etc/nova/nova.conf
dhcpbridge=/usr/bin/nova-dhcpbridge
libvirt_use_virtio_for_bridges=true

Thanks,
Xin

current behaviour

do search for role. If 1 found, return it. if none found, check my role list and return me if role is there.

This does not account for 'found 1 in search, but also myself as a role holder'. Hence get_lb_endpoint will not get called on this run (that only gets called when results > 1). It will require another run after this one, to wait for the indexing to complete, so that on the next run, I can find myself and the other node in the search.

If a floating ip is assigned to the management network, a host can incorrectly report the management network floating ip and end up in /etc/hosts incorrectly causing badness to ensure with live migrations.

I have been working with Rightscale and their integration with Alamo installs, and they require public IP addresses on their instances they create. Openstack supports auto-assignment of IP addresses, but this does not work on Alamo since the nova.conf gets regenerated on every chef-client run. We need a configuration option to persist this specific config option.

fresh install of chef and OS

Recipe Compile Error in /var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb

RuntimeError

Can't find network nova

Cookbook Trace:

/var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:289:in get_ip_for_net' /var/chef/cache/cookbooks/osops-utils/libraries/ip_location.rb:147:inget_bind_endpoint'
/var/chef/cache/cookbooks/mysql-openstack/recipes/server.rb:24:in `from_file'

"run_list": [
"role[single-controller]"
]

Multiple users (https://privatecloudforums.rackspace.com/viewtopic.php?f=4&t=301) are reporting that the autoetchosts recipe will overwrite /etc/hosts entries for compute nodes if a floating IP is assigned to an instance.

The exact situation is when the floating IP range is from the same network range as the host (management) network. This means on the public_interface, there will be two IP addresses from the same range if a floating IP is assigned. Chef will then update the /etc/hosts file with the floating IP as opposed to the IP originally assigned. This then impacts openstack functions when trying to communicate with other hosts (migration, etc).

The answer may simply be "don't use floating IPs from the same range as your physical hosts" but I wanted to open this issue to see if the recipe can be modified to help prevent this issue.

Steps to reproduce:

1. Create floating IPs from the same range as the management network
2. Assign floating IPs to instances
3. re-run chef-client on the compute nodes
4. check /etc/hosts to see if the entries have been modified