On Friday, January 24, 2014 12:36:39 AM UTC-6, Krist van Besien wrote: > > > > 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. >
The two statements are not directly related -- Foreman and Hiera are not mutually exclusive. I can understand, however, that you want to manage your site data all within the Foreman system. > Thus we also don't have per node manifests. > Few people do, I think, but I don't see how that's relevant. > 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. > Your general approach seems sound. Your duplicate resource problem arises from managing shared resources in the wrong place. You have the model backwards in that regard: resource declarations should not be exported as a means of saying "I need this resource", but rather as a means of saying "I *provide* this resource". The canonical example is Host resources, which manage entries in /etc/hosts. If each node exports a Host resource for its own name and IP address, and also collects all Host resources, then you end up with each node having all managed nodes listed in its hosts file. Each export says "My name is <my hostname>, and you can find me at <my address>." The nodes provide a machine (themselves) with the given name at the given address. >> 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. > > It is a good plan to allow root access only from the database host, but that in no way means database resources need to be collected into its catalog instead of being declared concretely there. As a first, minimally-elegant approach, define a class for each database, and assign those classes to the DB server via Foreman, as appropriate. Slightly more elegant might be to use a single class, driven by top-scope data defined via Foreman. If you were willing to put your data in a place and form where the master could access it via Hiera then a rather more elegant solution could be constructed. > 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. > Just like concrete resources, virtual resources may only be declared once within their scope (one catalog). They may be realized / collected many times, but that's not the same thing at all. Exported resources are just the same, except that their scope is the entire purview of a given master. They may be collected many times, for one node or for many, but they may have only one declaration. It's all quite consistent. John -- 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/c836e666-8844-46fe-8174-faade4cdfa61%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
