Puppet Resource Ordering not working

Question

I have a large manifest that sets up an OpenStack Controller node that also has HAProxy, Galera and RabbitMQ co-located on the same host. I am running into problems because the HAProxy service always seems to be the last thing to start. This creates a problem as I am suppose to connect to the Galera DB cluster through the HAProxies VIP. So all the attempts by the various OpenStack services are not able to set up their relational database tables. This would not be a problem if the HAProxy service starts first. I have tried all kinds of things to get my puppet manifest to force application of my HAProxy profile before anything else. Here's a couple of things I have tried:

    #Service <|name=='haproxy' or name=='keepalived'|> -> Exec <| |>
    #Exec<| title == 'nova-db-sync' |> ~> Service<| title == $nova_title |>
    #Service<| title == 'haproxy' |> ~> Exec<| title == 'nova-db-sync' |>
    #Service<| title == 'haproxy' |> ~> Exec<| title == 'Exec[apic-ml2-db-manage --config-file /etc/neutron/neutron.conf upgrade head]' |>

     Service['haproxy'] -> Exec['keystone-manage db_sync']
    #Class ['wraphaproxy'] -> Class ['wrapgalera'] -> Class['wraprabbitmq'] -> Class['keystone']
# -> Class['wraprabbitmq'] -> Class['keystone']
#
#   setup HAproxy
notify { "This host ${ipaddress} is in ${haproxy_ipaddress}":}
    if ( $ipaddress in $haproxy_ipaddress ) {
notify { "This host is an haproxy host ${ipaddress} is in ${haproxy_ipaddress}":}
       require wraphaproxy
#       class { 'wraphaproxy':
#           before => [
#              Class['wrapgalera'],
#              Class['wraprabbitmq'],
#              Class['keystone'],
#              Class['glance'],
#              Class['cinder'],
#              Class['neutron'],
#              Class['nova'],
#              Class['ceilometer'],
#              Class['horizon'],
#              Class['heat'],
#           ]
#       }
    }

The class wraphaproxy is the class that configures and starts the HAProxy service. It seems that no matter what I do the OpenStack Puppet modules attempt to do their "db sync's" before the HAProxy service is ready.

The question as worded implies that Puppet is executing the resource in the correct order, but that the service is not starting in real time when you want it to. Is this correct? — Matthew Schuchard, Oct 29 '16 at 13:35
Hi Matt, Thanks for the reply. I would like to ensure that HAProxy/Galera/RabbitMQ where up and running before the OpenStack services (Keystone,Cinder, Glance, Nova,Neutron, Heat and Ceilometer) attempted to do their "db sync's". — Red Cricket, Oct 29 '16 at 15:41
As a very poor workaround I remove the OpenStack services configs likes like /etc/keystone/keystone.conf after HAProxy has started and re-run puppet agent -t. This regenerates the configs and kicks off a "db sync" for the service. — Red Cricket, Oct 29 '16 at 16:14

score 0 · Accepted Answer · answered Oct 29 '16 at 20:13

0

OK. It turns out that I need to use HAProxy::Service['haproxy'] instead of just Service['haproxy']. So I have this in my code:

 Haproxy::Service['haproxy'] -> Exec['keystone-manage db_sync']
 Haproxy::Service['haproxy'] -> Exec['glance-manage db_sync']
 Haproxy::Service['haproxy'] -> Exec['nova-db-sync']
 Haproxy::Service['haproxy'] -> Exec['glance-manage db_sync']
 Haproxy::Service['haproxy'] -> Exec['neutron-db-sync']
 Haproxy::Service['haproxy'] -> Exec['heat-dbsync']
 Haproxy::Service['haproxy'] -> Exec['ceilometer-dbsync']
 Haproxy::Service['haproxy'] -> Exec['cinder-manage db_sync']

Please if someone out there knows of a better way by maybe using anchors or resource collectors please reply.

answered Oct 29 '16 at 20:13

Red Cricket

9,762
21
81
166

1

If you feel confident that all `exec` should occur after that service start, then you could always `Exec { require => Haproxy::Service['haproxy'] }`. – Matthew Schuchard Oct 30 '16 at 02:23
The issue there is the `Exec`'s are in third party code (the OpenStack community puppet modules). – Red Cricket Oct 30 '16 at 18:25
@RedCricket, that the `Exec`s are in third-party code does not necessarily conflict with using resource defaults, because [resource defaults have dynamic scope](https://docs.puppet.com/puppet/latest/reference/lang_defaults.html#area-of-effect). – John Bollinger Oct 31 '16 at 15:30
1

@RedCricket, on the other hand, if the `Exec`s are in third-party code then you may be able to target one or a small number of classes / defined-type instances with your relationships. Indeed, you *should* do so -- it's very poor form for one class or defined type to depend on implementation details of another, especially so if the other isn't even in the same module. – John Bollinger Oct 31 '16 at 15:33
@JohnBollinger Thank you for your reply. I might be a bit slow on the up take. Where the poor form? In my code or the third party code? Maybe I haven't researched the capabilities of the third party code well enough. – Red Cricket Nov 01 '16 at 05:38
@RedCricket, My criticism was prompted by the code presented in this answer, wherein a bunch of relationships are set up between `Haproxy::Service['haproxy']` and various specific `Exec` resources. Based on your previous comment attributing the `Exec`s to third-party code, those `Exec`s must be declared by a different class or classes from a different module, therefore the relationships constitute dependencies on the implementation of that class (those classes). It would be much better form to establish a relationship with the whole class, instead. – John Bollinger Nov 01 '16 at 15:26
Ah. Thank you for clarifying. How would I establish a relationship with the while class instead? – Red Cricket Nov 02 '16 at 19:53

Puppet Resource Ordering not working

1 Answers1