ceilometer-dbsync exits with a failure when applying the controller role for the first time on a clean system.

Notice: /Stage[main]/Ceilometer::Db/Exec[ceilometer-dbsync]/returns: 2014-01-30 12:12:31.182 26917 TRACE ceilometer ConnectionFailure: could not connect to 172.16.33.4:27017: [Errno 111] ECONNREFUSED
Notice: /Stage[main]/Ceilometer::Db/Exec[ceilometer-dbsync]/returns: 2014-01-30 12:12:31.182 26917 TRACE ceilometer
Error: /Stage[main]/Ceilometer::Db/Exec[ceilometer-dbsync]: Failed to call refresh: ceilometer-dbsync --config-file=/etc/ceilometer/ceilometer.conf returned 1 instead of one of [0]
Error: /Stage[main]/Ceilometer::Db/Exec[ceilometer-dbsync]: ceilometer-dbsync --config-file=/etc/ceilometer/ceilometer.conf returned 1 instead of one of [0]

The problem seems to be that puppet executes ceilometer-dbsync immediately after starting the mongod service, which does not always work out well because mongod takes some time to allocate a journal before it will accept incoming connections on 27017. On my VM this process takes about 15 seconds.

I know this is still in active development, but i figure i'd put this in anyway for tracking. ;)

The first time i apply on a new compute node, i always get this, because the /etc/libvirt dir is not there until the second run.

Error: Could not set 'file' on ensure: cannot generate tempfile /etc/libvirt/qemu.conf20140122-7044-wlkt22-9' at 36:/etc/puppet/modules/havana/manifests/profile/nova/compute.pp Error: Could not set 'file' on ensure: cannot generate tempfile/etc/libvirt/qemu.conf20140122-7044-wlkt22-9' at 36:/etc/puppet/modules/havana/manifests/profile/nova/compute.pp
Wrapped exception:
cannot generate tempfile /etc/libvirt/qemu.conf20140122-7044-wlkt22-9' Error: /Stage[main]/Havana::Profile::Nova::Compute/File[/etc/libvirt/qemu.conf]/ensure: change from absent to file failed: Could not set 'file' on ensure: cannot generate tempfile/etc/libvirt/qemu.conf20140122-7044-wlkt22-9' at 36:/etc/puppet/modules/havana/manifests/profile/nova/compute.pp

Hi,
I am attempting to use the puppetlabs-havana module and the puppet run fails on the controller node build when trying to run /sbin/service rabbitmq-server start

Error: Could not start Service[rabbitmq-server]: Execution of '/sbin/service rabbitmq-server start' returned 1:
Error: /Stage[main]/Rabbitmq::Service/Service[rabbitmq-server]/ensure: change from stopped to running failed: Could not start Service[rabbitmq-server]: Execution of '/sbin/service rabbitmq-server start' returned 1:

If I run that command manually, I get the same error. As expected.
If I "service iptables stop" I can run the command successfully.

On the next puppet run, it got further, but errored like below:
Error: /Stage[main]/Nova::Rabbitmq/Rabbitmq_user_permissions[openstack@/]: Could not evaluate: Execution of '/usr/sbin/rabbitmqctl list_user_permissions openstack' returned 2: Listing permissions for user "openstack" ...
Error: unable to connect to node 'rabbit@controller-1': nodedown

DIAGNOSTICS

nodes in question: ['rabbit@controller-1']

hosts, their running nodes and ports:

• unable to connect to epmd on controller-1: address (cannot connect to host/port)

current node details:

• node name: 'rabbitmqctl21552@controller-1'
• home dir: /var/lib/rabbitmq
• cookie hash: jeksUQHfkCxLqaPwlesT0Q==

Again if I stop iptables and run it manually it runs successfully.

Adam

The exec's which shut down libvirt on each puppet run (in compute.pp) and then start it back up again aren't really good. Some workaround should probably be found so that the nova module can work nicely with the firewall module without having to do this.

When using the earlier grizzly module for some demos we had an issue where iproute was not upgraded to the RDO version and had to do a manual upgrade of that before Neutron (then quantum) would work.

I haven't digged into the havana code yet but will watch for this when I do - hence this bug report. Don't know if anyone else has seen the same behaviour?

My user roles seem to do this every time (notice the order of admin and member flips):

Notice: /Stage[main]/Havana::Profile::Keystone/Havana::Resources::User[cturner]/Keystone_user_role[cturner@test]/roles: roles changed ['admin', 'member'] to 'member admin'

To fix that I reversed them in resources/user.pp. Seems to work.. roles => ['admin', 'member'], to match the sorted order they come out of the provider in.

The proper fix is probably to sort them in the provider somewhere.

Warning: Scope(Class[Nova::Keystone::Auth]): cinder parameter is deprecated and has no effect.

I believe the parameter should be removed from profile/nova/api.pp.

I've set up my network using two NICs as follow

auto br-ex eth0 eth1 lo

allow-hotplug br-ex eth0 eth1

iface br-ex inet dhcp

iface eth0 inet static
address 0.0.0.0
down ip l s $IFACE down
up ip l s $IFACE up

iface eth1 inet static
address 10.0.0.102
netmask 255.255.255.0

And my hiera

######## Networks
havana::network::api: '200.232.7.0/24'
havana::network::external: '200.232.7.0/24'
havana::network::management: '10.0.0.0/24'
havana::network::data: '10.0.0.0/24'

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

havana::controller::address::api: '200.232.7.102'
havana::controller::address::management: '10.0.0.102'
havana::storage::address::api: '200.232.7.102'
havana::storage::address::management: '10.0.0.102'

I've created my ext network with options

| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | 31c76aec-0a1f-46d9-989d-c5a3b97d0ef0 |
| name                      | external                             |
| provider:network_type     | gre                                  |
| provider:physical_network |                                      |
| provider:segmentation_id  | 1                                    |
| router:external           | True                                 |
| shared                    | True                                 |
| status                    | ACTIVE                               |
| subnets                   | b69d91e5-e86c-4956-8229-09c5d6e68a07 |
| tenant_id                 | 6ca99f9d5f8b4a2aa17967a7e8e6915a     |
+---------------------------+--------------------------------------+

My VM can get IP and I can ping metadata/gateway IP with
ip netns exec qdhcp-31c76aec-0a1f-46d9-989d-c5a3b97d0ef0

But inside my VM nothings happens.
I'm trying to see if is firewall related issue.

Hi, I am trying to use puppet to deploy openstack havana, but I get this:
Error 400 on SERVER: Could not find data item Havana::controller::address::management in any Hiera data file and no default supplied at /etc/puppet/modules/havana/manifests/resources/connectors.pp:3 on node controller

on the server I have hiera.yaml in /etc/puppet with common.yaml in /etc/puppet/hieradata
But it looks like it can't find them

[Private Network]
Management Network:172.16.33.0/24
Data Network 172.16.44.0/24

[External Network]
API Network & External Network is set in the same network which have access outside.

Rest were set almost the same as in this video:
https://www.youtube.com/watch?v=hTrWcGHsHh4

Thanks for any hint

Not sure if you'll consider this an issue, but i figure i'd put it in just in case :)

I set up a role modeled after your havana roles with some different options. I didn't include firewall, choosing to manage that myself.

Issue 1: Without firewall, the yum repository never gets installed. (which obviously causes stuff like nova etc to fail to install)

Issue 2: If i do use firewall, the openstack yum repo module conflicts with our internal yum repo setup stuff.

Most ideal for my purposes would be if i could use your firewall module, but disable the yum repo setup step (either separate the yum setup into a separate class file called in the role, or let me disable it with a hiera option). With it split out into a separate class, i could manage that myself and still use the firewall. It makes logical sense to have it separate anyway, since its required by every other step, not just the firewall.

On centos 6.5, i sometimes get this when provisioning.

Error: /Stage[main]/Cinder::Setup_test_volume/Exec[/sbin/pvcreate /dev/loop2]: Failed to call refresh: /sbin/pvcreate /dev/loop2 returned 5 instead of one of [0]
Error: /Stage[main]/Cinder::Setup_test_volume/Exec[/sbin/pvcreate /dev/loop2]: /sbin/pvcreate /dev/loop2 returned 5 instead of one of [0]

If I set up a cinder-volume node(havana::profile::cinder::volume) iscsi_ip_address is set with controllers management IP and it should be set with the local management IP, otherwise isn't possible to attach a node volume.