Will, Thanks for the response. I know its a bit of a unique model -- but when you think about it, it makes a decent amount of sense. We run hundreds of nodes that are fundamentally similar .. i.e. "this is a web server, it gets the XYZ package installed" and "this is a web server, it gets the ABC package installed". Using hostnames to identify the systems node-definition makes very little sense and leaves quite a bit of room for error. Explicitly setting the node-type as a fact allows us to re-use the same node types but for many different environments and keeps host-names out of the mix. For example, I can quickly boot up a "prod-mwise-dev-test-web-sever-thingy" using the same node definition as our "prod-frontend-host" for some testing, without worrying about the hostname regex structure.
Anyways that said ... what I'm really interested in knowing is why the puppet-agents are pulling DOWN their "node information" from the puppet masters? Is it possible that they do an upload of node information, then ask for that information back, then somehow use the downloaded information for their catalog request? I could see some interesting race conditions if that was the case. Matt Wise Sr. Systems Architect Nextdoor.com On Fri, Aug 22, 2014 at 7:11 PM, Wil Cooley <wcoo...@nakedape.cc> wrote: > > On Aug 22, 2014 7:37 AM, "Matt W" <m...@nextdoor.com> wrote: > > > > Anyone have any thoughts on this? > > > > I have to say, using an identical node name as a way of assigning the > node's role is an "interesting" approach. I would not be surprised if you > run into other difficulties with this approach; some even harder to find. > Even something like an appended unique identifier, such as from the host > ID, MAC address, serial number, hashed SHA1, etc would have been better. > > Be that as it may, life would be dull if we didn't have to live with the > sins of the past. You might check the config guide > https://docs.puppetlabs.com/references/3.6.latest/configuration.html but > in thinking about it, if you found a setting and tried to use a fact in it, > you'd probably just get the master's fact. > > The reports, at least, should be easy - since they're pluggable, you could > copy the existing "lib/puppet/reports/store.rb" to a new name & module and > tweak the storage location. > > Wil > > > On Thursday, August 14, 2014 10:39:16 AM UTC-7, Matt W wrote: > >> > >> We noticed that our puppet reports and our puppet node data stored on > our puppet servers is always written out in the form of the 'node name'. So > when we use a node name like 'prod_webserver' across many webserver > machines, we get a tree of reports and node data like this: > >> > >>> /var/lib/puppet/yaml/node/prod_web.yaml > >>> /var/lib/puppet/yaml/facts/prod_web.yaml > >>> /var/lib/puppet/reports/prod_web > >>> /var/lib/puppet/reports/prod_web/201408130200.yaml > >>> /var/lib/puppet/reports/prod_web/201408140811.yaml > >>> /var/lib/puppet/reports/prod_web/201408121328.yaml > >>> /var/lib/puppet/reports/prod_web/201408130743.yaml > >>> /var/lib/puppet/reports/prod_web/201408140454.yaml > >> > >> > >> Where each of those reports likely reflects a compilation run for a > different host... and the facts/node files at the top are getting > constantly re-written as new clients come in. > >> > >> Is there a way to change the behavior of the data there to be written > out based on the ${::fqdn} of the host (or certname) rather than its node > name? > >> > >> (our client puppet configs ...) > >>> > >>> [main] > >>> ... > >>> node_name = facter > >>> node_name_fact = puppet_node > >> > >> > >> (a client puppet fact file...) > >>> > >>> puppet_node=prod_web > >>> puppet_environment=production > >>> package=frontend=some-version-here > >>> app_group=us1 > > > > -- > > 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/40c0048d-fc90-4006-99da-98bfa9ba94a7%40googlegroups.com > . > > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/adxt68xO210/unsubscribe. > To unsubscribe from this group and all its topics, 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/CAMmm3r5MwNDV%3DCEnxVrr4pL1w_Xi3byR5xphPxPZH3%3D2XgJdXQ%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-users/CAMmm3r5MwNDV%3DCEnxVrr4pL1w_Xi3byR5xphPxPZH3%3D2XgJdXQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAOHkZxNL_RbmL6Hzj1qOFas%3Dn4n4vUyemSE1Qro%2B2XF4pA9Otg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
