Foreman Installer sets the module path to: /etc/puppet/environments/common:/etc/puppet/modules:/usr/share/puppet/modules. I believe the environment module path takes precedence over those paths... so if you have multiple versions of a module in the path and the environment, it's the environment's module that gets discovered in foreman. It's been a while since I've run into that situation, but that's how I remember it working.
On Monday, March 6, 2017 at 2:15:54 AM UTC-5, Marek Hulán wrote: > > Thanks for the answer, definitely worth investigating. I suppose in this > case > where you put shared modules into ignored common env, you can't have two > different versions of the same module for each org. Or did I miss > something? > Anyway it's a good start. > > -- > Marek > > On středa 1. března 2017 13:59:56 CET Sean A wrote: > > Hi, > > > > We have a similar problem. There was a post by me a while back which > > discussed this. Basically, Foreman assumes an environment has a set of > > classes, regardless of what puppet master that environment exists in. > So > > to solve this for us, we are deploying environments specific to puppet > > masters by organization. > > > > In your example, with ORGA and ORGB, we would have environments named > > orgaprod, orgadev, orgbprod, orgbdev, and the "common" module directory > > that foreman deploys as an environment set to be ignored by foreman but > > still in the modulepath. We deploy enterprise level modules to the > common > > module dir, then let the org's admins manage their org specific > > environments. > > > > I can't say it works great just yet, because we are trying to fit this > into > > an existing environment. It has worked very well in clean test labs > where > > nothing pre-existing was setup. > > > > On Wednesday, March 1, 2017 at 9:56:23 AM UTC-5, Marek Hulán wrote: > > > Hello Foreman users, > > > > > > I wonder how people using multiple organizations in Foreman manage > their > > > puppet modules. Let's assume I have two organizations A and B and I > want > > > them > > > to be isolated as much as possible. Since puppet environments can be > > > scoped to > > > organization, we can have separate environments for each organization. > > > Well, > > > as long as they have unique name, since the validation prevents to > have > > > two > > > environments with the same name even if they are in different > > > organizations. > > > > > > But the bigger issue seems to be is how puppet classes should work, > since > > > they > > > are not scoped to organizations. When user in organization B tries to > > > import > > > the class with the same name that users from organization A already > > > imported, > > > it fails saying the name has already been taken. In theory the > > > organization > > > should be clear from environment but what if I have two separate > > > environments > > > for organizations and they want to use same puppet module? And what if > > > their > > > puppet modules have different versions so the smart class parameters > > > differs? > > > > > > And does using katello content views with puppet modules helps in this > > > case? > > > It creates different puppet environment for each content view version > but > > > is > > > there the same problem for puppet class name collision? > > > > > > Is there some workflow I'm missing? If you have such use case but yout > > > (same > > > as me) can't solve it with Foreman, how would you change Foreman so it > > > fulfills your needs? > > > > > > Thanks for any suggestions > > > -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
