On Thu, May 9, 2013 at 6:56 AM, <[email protected]> wrote: > Issue #12173 has been updated by John Bollinger. > > > eric sorenson wrote: > > The idea is that we should restrict puppet-master processes to one > environment per process; it’s the only deterministic way to avoid the > problem as stated. > > Are you sure about that? As the old saw goes, “any problem in computer > science can be solved with enough layers of indirection.” It seems to me > that this issue could be addressed by interposing per-environment classes > or (Ruby) modules into which native plugins are loaded, and from which they > are resolved / used. Perhaps implementing such a thing would require > touching a lot of code, but given the amount of metacode in Puppet, I don’t > think that’s a given. > Unfortunately we're fairly confident process-per-environment is the least-poor way to proceed. We'd prefer to solve this using interposing per-environment classes or some other form of containment. I haven't been able to find a suitable container in MRI though. Java has a sophisticated class loader which would be an effective tool in this problem area. Ruby lacks this level of sophistication with regard to class loading. Anonymous classes are possible in Ruby, but a way to keep track of these anonymous classes needs to be built and maintained. Furthermore, anonymous classes have an annoying property. When an anonymous class is assigned to a constant, the class assumes the identity of the constant. This seems intuitive, but Puppet refers to classes using constants all over the place, like Puppet::Type::File:
irb(main):005:0> Puppet::Type.type :file => Puppet::Type::File Even if a sophisticated anonymous class manager lived behind the `type` class method, all of the other anonymous :file classes would be inaccessible as soon as one of them is bound to Puppet::Type::File. We'd have to re-assign the constant over and over, which is difficult because constants are not thread safe. At this point we'd have to build and manage a fairly sophisticated lock manager and we've made the entire system inherently thread un-safe. This leaves us with eliminating every place where a type or provider (or any extension for that matter) class is assigned to a constant. That's a pretty massive undertaking, especially considering the relative lack of Ruby refactoring tools and the heavy use of meta-programming inside the Puppet RAL. Which leaves us with the process itself as the next level of abstraction... Or switching to another runtime environment for the master, like the JVM, but even then we'd need to have different jruby heaps so the efficiency benefit is unclear. > In any case, surely it would be better to find a way to make the feature > work as it was always promised to do, instead of pulling back with an > “oops, no can do.” > I've been wracking my brain for years on this one... and I'm out of fresh ideas. Do you see anything I'm overlooking with the way MRI behaves? We're moving to 1.9.3 now, so perhaps there's some new behavior I'm unaware of compared to 1.8.7 and earlier versions. -Jeff -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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 http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
