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.
