On Thursday, January 23, 2014 10:26:08 AM UTC-6, Krist van Besien wrote: > > > > On Thursday, January 23, 2014 2:59:29 PM UTC+1, jcbollinger wrote: >> >> >> It only makes sense to export resources that are somehow specific to or >> characteristic of the node whose catalog is being compiled. If you have >> such a resource to export, then structure your manifests so that no more >> than one declaration of the resource can be evaluated during any catalog >> compilation. No need for any tests in that case. If different nodes may >> export *similar* resources, then do ensure that they all have distinct >> titles (and names) across all nodes. >> >> On the other hand, if your resources are not characteristic of any >> particular node, then they are not suited for export. We might be able to >> suggest specific alternatives if you explained what you are trying to >> achieve in more detail. >> >> > Basically my situation is the following: > - A database server > - Several web application servers. > > The whole managed using foreman/puppet > > My Web applications each need a database, so I would like to just export > on the web application nodes the databases I need, and collect them on the > database server. However, several nodes that run the same web application > of course need the same database. What do I do when I have two nodes, that > both need the same database? > The logical, intuitive solution would be to export it on all of them, but > only collect it once on the database server. > >
No, that's not sensible. It presents largely the same problem as multiple concrete declarations of the same resource within one node's catalog. All declarations of the resource must be kept in sync, and no one of them is authoritative. Even if they all happen to be identical during any given catalog compilation, Puppet rejects the duplicates. I imagine you saying that the declarations in your case are automatically in sync because all the nodes in question issue it via the same manifest. If that's the case, however, then the declaration must not depend on anything specific to the nodes consuming the database, therefore it could just as easily be declared as a concrete resource on the database server. That has the added advantages that 1. The database can be configured before any of its consumers are 2. The database does not fall out of management if its consumers go down / stop checking in 3. It's possible to determine what databases are supposed to be configured strictly by looking at the manifests and data pertinent to the database server > Other situations are : backends to a loadbalancer that export both > frontend and backend URLs. The loadbalancer collects both, and creates it's > configuration based on them. > > Back ends shouldn't be telling the LB what its front-end URL is. That is and should remain a property of the LB itself. On the other hand, it is quite reasonable for the back ends to export *their own* URLs for the LB to collect. That's actually a pretty good example of what should be exported and what should not. 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/d2b587ed-d84b-47c7-9fa5-26bef4ef2e70%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
