On Thursday, January 23, 2014 7:25:47 PM UTC+1, Xav Paice wrote: > > > We have something quite similar - as we use hiera extensively we managed > to have a common yaml file with a list of databases in a hash, and used > create_resources to create the databases (and users, and haproxy > listeners) on the database/haproxy nodes. > > The application nodes that want to register with a load balancer export > resources for themselves only, which are collected on the load balancer > only. >
We don't use Hiera. We use foreman as ENC. Thus we also don't have per node manifests. What we do have is our own module, with classes we assign to host groups in foreman. We define a host group for or different categories of servers, and assign hosts to a host group based on what they are supposed to do. So if we for example want to add another backend we just create a new host in foreman, add it to the right host group, and then flip a switch. It powers on, bootstraps itself, installs all it needs, and exports what it needs from other servers. However we run in to the problem of duplicate external resources, which I have for the moment resolved through some ugly hacks. > > An alternative is to have a manifest that ensures there is a suitable > database available, creating it if not, running on the web application > servers - you've got a db client there already which should be able to > access the db server. That approach also allows you to ensure there's a > database created before attempting to populate it and start the app, > exported resources mean you'll need several runs before everything is > clean. > > For security reason we only allow root access to the mysql database from the host it runs on, via a unix socket. That is why the DB server needs to collect the databases and then create them. But that problem seems solvable also. But I am still interested in a general solution- We have "virtual resources". This has allowed me to for example declare all the different VLANs in one class that all nodes include, but then only realize the lans needed on a per service basis. Something like "exported virtual resources" would be convenient. We also run in to trouble for example when dealing with users. We use a lot of the openstack classes on puppetforge. Some of those classes will try to create keystone user resources. Again these should be exported so the keystone server can collect and create them. But again, only once... -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1075d1ba-36b7-4eec-ad2c-95b76b59d1e2%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
