On Monday, June 27, 2016 at 6:42:58 PM UTC-5, Alex Samad wrote: > > On 27 June 2016 at 23:33, jcbollinger <john.bo...@stjude.org <javascript:>> > 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. > >
We have given you several reasons why. Examples include, - "[for your purposes] environments do not provide a benefit commensurate with the extra complication and work they involve." - "Environments is a very big hammer for whats basically a tiny nail you're describing." - "Puppet environments are highly appropriate for change management in your Puppet infrastructure itself [, but ...] There is no good reason for coupling that with change management for your product / service pipeline." - "The reason there is no direct relationship between ['operating environments' and 'puppet environments'] is because a node that is in the operational status of production [for example] can switch between the [Puppet] production environment and any other environment of your puppet code without affecting its operational status." - "This data is better separated via hiera." We have also talked a bit about the uses to which environments are better suited; for the most part, using them for the purposes you propose interferes with using them (later) for those more apt purposes. I'm sorry if these seem to be higher-level claims than you would like to hear, but I'm uncertain how to answer in any deeper detail. > 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. > As I said from the beginning, your machines themselves do not (or should not) care to which Puppet environment they are assigned if you are performing those assignments centrally. So yes, you can go back and forth among different approaches on the master's side. > > 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. > > Roles and profiles are implemented via classes. What you seemed to have said suggested that even roles and profiles was more complex than you really needed. Nevertheless, the one class per machine group maps directly to one role per group, and can be implemented that way. There is no essential inconsistency here. Your subsequent comments make me think that your real requirements are at least a bit more complex, as indeed I had initially supposed when I first suggested roles and profiles. 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. > We already covered this. The conventional ways to approach problems of that sort are via hiera or via your ENC. There are many ways to implement the details. > > 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 ? > Supposing that the classes you are applying to your nodes are built to accommodate it (mainly that they rely on external data), you do it by binding different data to some nodes than you do to others. Again, details vary. 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/531d464d-8edd-45f5-ab43-0e7818f2b1b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
