In regard to: Re: Requires: python(foo) = bar, Jeffrey Johnson said (at...:
On May 11, 2012, at 2:46 PM, Tim Mooney <tim.moo...@ndsu.edu> wrote:
In regard to: Requires: python(foo) = bar, Jeffrey Johnson said (at 2:11pm...:
Matthew Dawkins mentioned an interest in better python module
dependencies in RPM earlier today.
I'm still running rpm 5.1.9 and meaning to upgrade, but I've been meaning
to ask about ruby dependencies. For better or worse, ruby is becoming
a big party of my life.
Specific questions:
1) Would rpm-ruby bindings be useful to you?
Maybe some day, but at this point, not really. I don't actually want to
interface with rpm from ruby (yet, and maybe not ever), I just want rpm
to automatically figure out all the junk (module or gem) that is required
when I rpm install something like rubygem-puppet-lint.
2) Are you doing DevOPS? I'd like to see a unification of
configuration <-> package
management, actually looked at puppet/chef/cfengine 6 weeks
ago.
Yes, that's what's driving ruby in our environment: puppet.
cfengine would be easiest to link into RPM and has
definite design strengths (i.e. I like "promises"). But
clearly PUPPET! PUPPET! PUPPET! is the loudest chant
from the Linux advocates everywhere.
It does have tremendous momentum. It's changing a lot and is
a serious moving target, though. A lot of what was done in our
environment when our primary puppet advocate was beginning to deploy
puppet here will need to be reworked considerably for the forthcoming
puppet 3.0.
Meanwhile I was underwhelmed with most of what I saw
with DevOPS: simple tasks became hugely complex and
there were no apparent complex tasks that the tools simplified
enough to interest me. But that was merely a drive-by
review of current state-of-the-art; I'm sure there
are features/benefits that I entirely missed in all
of the 3 DevOPS applications (2 in ruby) that I looked at.
I'm hard pressed to say that you're wrong; There is a lot (I mean *a
lot*) of work that needs to be invested up front to get any benefits
out of devops. If there's much variation in one's environment (as there
is in an academic environment like mine) that also adds a lot of
complexity, and it's complexity that one isn't necessarily prepared to
handle when they're initially rolling out something like puppet.
The benefits start to become pretty significant once you have a good
portion of your hosts included in your CM infrastructure. It's really
nice to be able to make one change (like remove a sysadmin when he leaves)
in one spot and have it automatically applied to your entire environment
automatically. Or know that your entire web farm is configured
identically *and* will be re-configured to be identical even if an admin
makes a change "just for testing" on just one of the web servers, and then
forgets to either undo or propagate it.
It's no panacea, but once you get critical mass, the benefits do start
to become much more apparent.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
