Alex, I will be brief(ish) this time, since wordiness seems not to be working. I've been around Puppet for a fairly long time, and I think I know what I'm talking about, but by all means do evaluate my claims for yourself.
On Friday, June 24, 2016 at 9:20:58 PM UTC-5, Alex Samad wrote: > The point i was trying to make was not the how. But that a group of > nodes will have 1 config and another a different config. It seems > like environments would be the way to group that. > Your ENC does the grouping. Environments are *one* way to organize each group's manifests and data, but multiple people are advising you against using them that way. > Surely you don't > > suppose that every machine in the same operational environment will be > > configured identically to every other, so even if you do match Puppet > > environments to operational environments, that does not in itself > address > > questions about how to assign configurations to nodes -- or, in Puppet > > speak, how to classify nodes. > Why can't I expect that. if I expect puppet to look after things like > MOTD, SSHD config, smtp config, firewall config. users. SOE directory > setup. Why can't I expect them to be the same. I understand that ip > address and name will be different. > Evidently you *do* suppose. Wow. Most people have machines of different kinds under management -- web servers, database servers, workstations, etc.. These normally have some commonalities in their configurations -- maybe many commonalities -- but their overall configurations are not identical. If indeed no machine in any of your groups is distinguishable from any other in the same group except by its network identifiers (hostname / IP / MAC) then Puppet environments are even less appropriate for you than I thought. In that case, the key thing you should do is define one class per group, and have your ENC assign the appropriate one of those classes to each machine. > > In the first place, this still has nothing to do with nodes being > mindful of > > which Puppet environment they are assigned to, nor even of which > operational > > environment they are assigned to. Nodes will use whichever winbind (for > > example) is installed on them, regardless of which environments you > label > > them with. The nodes themselves don't much care what you call them -- > they > > simply operate according to the way you configure them. > > But ... this is what i want to use puppet for. You're missing my point. Which winbind (as an example) is installed on a given node can absolutely be managed by Puppet. The point is that the nodes themselves don't need to know which Puppet environment -- or even which operating environment -- they are assigned to; they just use whichever winbind they currently have (as managed by Puppet). > when i say want to - I would like to. if i want to roll out a new test > version of winbind I had presume I would just change the package > modules for winbind to a newer version and it would roll out for that > environment - I would plan to leave it there for a week or month or > two to test. then once satisfied move than onto production. > And you can do that with Puppet. You just shouldn't use Puppet environments as your mechanism for mapping which nodes get which package versions. > > > > In the second place, if the master has enough information to determine > > nodes' intended operational environments, and it knows how nodes in > those > > operational environments should be configured, then it can configure > those > > nodes appropriately. If not, then not. Puppet environments are one > vehicle > > would i then need to have lots of if statements or ??? > No. It's a question of defining and assigning appropriate classes, and of associating the correct *data* with each node. I cannot overemphasize the importance of data -- this is everything from which versions or which packages are supposed to be installed, to which users, to which servers to rely on, to the contents of the MOTD. One of the most fundamental lessons of the last seven or so years of Puppet has been that externalizing data of almost all types is a tremendous win. 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/3d5d1615-0506-4373-a507-ca586cb3a397%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
