Well, I have to say that after a few hours of reading up on ruby, rvm, and the gems mechanism, I an VERY unimpressed with ruby, from the perspective of systems management. it may be a great language to write; I have no opinions on that, honestly. But ruby has clearly learned nothing from the various interpreted language that preceded it.
As for puppet's assumption about an unreliable network, that's really only true in the sense that it recovers from network failure, and picks up where it left off elegantly. You want that from any service, whether it's network based or not. Things die -- if you don't handle crashes and loss of connectivity (even connectivity to a local, non-networked service) you don't have a very robust mechanism. My goal was really just to be able to manage puppet out of EFS, since it can clearly benefit from the versionized namespace. I am no longer sure it's worth trying to integrate ruby the same way we've done perl, and have at least prototyped python. The language's ABI is way too fragile, and backwards compatibility has been a pipe dream. I think a better approach would be to build a puppet release by first building, into the SAME release, the specific version of ruby and all the ruby libraries/gems it needs. Ruby itself is at least configure-based, and then all the tools assume that you're installing things on top of the core ruby, so if you do that, and then just install puppet, you can create a single, monolithic release that is bundles together. Given the extreme fragility of ruby, certainly when compared to perl, this is probably the only reasonable thing to do in the short term. On Thu, Jan 13, 2011 at 3:32 PM, Steven Jenkins <[email protected]>wrote: > On Thu, Jan 13, 2011 at 3:16 PM, Phillip Moore > <[email protected]> wrote: > > > > Well, if I was going to live within their walls, I wouldn't be trying to > > build this inside of mine. > > The whole point of EFS is creating a common, shared distribution > > infrastructure, so you don't have to use specific mechanisms for each > > product you work with. So far, it looks to me like ruby is way behind > perl > > with respect to this sort of scalability, but it's clearly evolving. > > It might be interesting (and Ruby-like as well) to do a rubygems > replacement that assumes the existence of an EFS infrastructure > underneath. However, you can do much the same with Gemfiles: e.g., > > gem "package1", "alpha" > gem "package2", "2.2.2" > .... > > i.e, within the Gemfile specifications, the required packages and > versions are already specified. > > The more interesting problem (i.e., multiple versions and > implementations of Ruby co-existing, and sharing/not sharing gems) is > where RVM is used, so I think there's space there for EFS. In other > words, RVM is what the individual developer will use, but it's > not-so-sharable across an enterprise where you will want to share > gemsets, for example. > > Can you expand on what your thoughts are for a design for Ruby? > > > My goal is to get this all integrated so that I don't have to install > puppet > > locally anywhere, and can use it to manage system configuration, and a > bare > > minimum of software installation. Even puppet can reap huge benefits > from > > using EFS as a mean of deploying upgrades to the puppet infrastructure. > > Also, another key point of centralized network-based software deployment > is > > to minimize the amount and complexity of the data you HAVE to manage > local > > to each node. Puppet appears to do that very well, but it can NOT solve > the > > myriad of problems that EFS solves by allowing independent versions to > > co-exist. You are still constrained by rpm/apt-get/pkgadd and their > > numerous limitations if you struggle to manage local installations of > > software. > > One of the difficulties Puppet tackles (and problems with it, IMO) is > that it does not assume a reliable network filesystem. If that > assumption can change, much of the complexity can be removed. I think > that would be very useful and interesting. > > Steven > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
