On Monday, July 21, 2014 1:28:11 AM UTC-5, David Schmitt wrote: > > On 2014-07-16 20:34, José Luis Ledesma wrote: > > I don't think this is true. Master compiles a catalog based on facts, it > > does not mind if there is a previous compilation with a complete list of > > different fact values. > > Even if the master is able to handle quickly changing facts, every > module that relies on export/collect will be terminally broken. > >
Not so fast. In the first place, comparatively few modules do rely on export/collect, and there's no particular reason to think that any of those are relevant. In the second place, breakage of such modules assumes that the *specific* facts they rely on would change from one (virtual) machine to another among those sharing a cert. Inasmuch as the discussion is about a collection a VMs originating as clones of the same master image (and, as initially conceived, each having the same hostname), I would suppose that many of the core facts would anyway be identical among this collection. As I said earlier, it's probably not a wise plan to share certs. Issues such those we've been discussing are why. It is likely easier to just give each VM instance its own cert than to undertake the effort to ensure that sharing a single cert works smoothly. But if you were determined to share a cert, and you were willing to accept the limitations that imposed, then it could be made to work. 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/ca25ba43-5366-4c3c-bee6-8e42b53d49b4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.