On Thursday, September 25, 2014 3:33:00 PM UTC-5, Andy Parker wrote:
> The language will remain in ruby for a while yet (the puppet-server uses > JRuby to run the puppet ruby code), and even after the interpreter gets > reimplemented in a faster language, ruby will be available for extensions. > It would simply be too much of a change to drop ruby and drop all of the > custom code and extensions that everyone has worked so hard on. > > I feel compelled to point out that if the "faster language" happens to be C++, then you will *need* a plug-in interface in some different language (presumably Ruby, but straight C would be more typical). C++ APIs are sensitive to compiler and compile options used, and they provide essentially no compile-time encapsulation of API classes' private members, so it would not be wise to suppose that you will ever be able to directly support unwrapped, third-party, C++ plugins. Especially with the current fast pace of Puppet development. > What *might* be happening very soon is dropping rack and webrick support > and moving entirely to the puppet-server. It provides a much simpler setup, > better performance, and more controlled environment for us to target. > > "Puppet apply" will be sticking around. The exact way in which it will > work isn't completely clear yet. There are several possibilities from > requiring the jvm on all nodes that run puppet apply to changing apply to > use a "compile server" to actually run manifests or possibly reimplementing > the interpreter in a non-jvm language and using JNI to make it available on > the puppet-server. My currently leaning is to implement the language in a > jvm language and requiring that a masterless setup has the jvm on the node. > Although I have no problem with the JVM in general, I am not at all keen to have JVM installation as a pre-requisite for bootstrapping Puppet on nodes. I am supposing that the plan is to not require that for the *agent*, but I don't think it's wise for "puppet apply", either. Moreover, there are machines and organizations for which any client-side dependency on the JVM would be a complete show-stopper, and that would be a big concern for me if I were making this decision. Furthermore, it's unrealistic to suppose that users of masterless Puppet would accept a solution involving an external "compile server" as a *bona fide* substitute for the current implementation of "puppet apply". That's barely different from running the agent. The whole point of "puppet apply" is that you don't rely on any other machine to apply your configuration. You could try to maintain separate, parallel catalog builder implementations, but I promise you that that would get old (and expensive) very quickly. So what catalog builder alternatives are left? Let's see... you need a light(ish)-weight language and runtime environment with few detractors, yet you also want to be able to run in the JVM. For community acceptance, you need to support plugins implemented in Ruby. How about using ...*drumroll*... Ruby? I hear PL has one or two Ruby programmers already ;-) Is JRuby so different from (C)Ruby as to preclude writing code that works on both? 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/68a50a9e-e45f-46d7-8925-1953354d4ee3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
