On 27 June 2016 at 23:33, jcbollinger <john.bollin...@stjude.org> wrote: > > 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.
I have come to the list to get the input from people like yourself with experience. I am in the learning stage. So I am taking in stuff. and maybe asking silly questions. But what I like to hear is why, not just being told what to do. I have heard environments is not the way to go, but not why what is the down side. I have also heard from other people who use it a lot that they use a lot of environments. I've have decided to give it a go under 2 envornments and try and map my machines in some other grouping under production. I presume I can always go back. > > 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. Okay - what is the down side ... ? Note I am going to try the single environment setup > >> > 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 There are going to be a lot of commonalities (i believe), standard patching, standard security, standard ... these are typically company wide. But my current environment small number of nodes. we have app, web, rp, mail, proxy servers, but they have quite a lot in common. > 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. Q) why classes - i thought the way to go was roles / profiles. I have defined a who bundle of profiles - like for example one for ssh - have company standard setup for ssh, and other packages that are part of the SOE. Then I will have roles which will be a collection of profiles. those roles will be things like web server, app server, proxy server etc etc. ? are roles and profiles made up of classes, are classes the fundemental building block in puppet and the term role / profile is just a type of class ? > > >> >> > 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). Yes I understand that, but how (again try and explain how not that I shouldn't). So I have 1 environment production I have my prod server in the prod grouping ??? I have my standard profile MY Winbind. its linked to a specific version. How do I now test a new version. I presume in my "MY WInbind" class I need some statements to say if in prod then this version if in test this version. Is this the way to do it ? > > >> >> 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. Again why ? Too much overhead too much???? Why have R10K if you are meant to have lots of environments > > >> >> > >> > 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 This data - maybe this is what I am missing from the picture http://www.craigdunn.org/2012/05/239/ somebody pointed to this blog covering profiles/roles. Looking a the diagram in the bottom showing resource -> modules -> profiles -> roles -> node it links in the data -> hiera which inserts into profiles and modules. Maybe this is what I need to understand better .. > 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 a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/mZBLZQKZ0xM/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/3d5d1615-0506-4373-a507-ca586cb3a397%40googlegroups.com. > > 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/CAJ%2BQ1PUsFOeug2sfs0Aqxj0wHDDgh%3Dbv4rFU%3DZ1M2uU_O2GSSg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
