[users] [Fwd: RPMforge/Repoforge and Puppet]
ian at iay.org.uk
Wed Nov 21 17:37:32 CET 2012
On 21 Nov 2012, at 14:53, "Yury V. Zaytsev" <yury at shurup.com> wrote:
>> I guess I
>> could just try this on a clean VM and see, though; it may be to do
>> with their Enterprise offering which I think is what's in that VM.
> It would be nice if you could later share the results of your research!
I just tried this with a random VM I wasn't using for anything else.
First observation is that the puppet from Puppet Labs' repository does seem to put its configuration etc. in /etc/puppet. So it looks broadly compatible. The default configuration file is identical, too, and the directories it refers to (in particular, $vardir) also appear to be in the same places.
Second point is that it's version 3.0.1, which is obviously a significant step up from the 2.7.x on Repoforge. For example, it requires a newer version of Ruby than is shipped in RHEL/CentOS 5 (1.8.5), and they include Ruby 1.8.7 in their dependencies repository to support that.
They also include ruby-augeas and rubygem-json packages in their dependencies repository which are detected as being older than the ones in repoforge. So even applying priorities in various ways, I end up with a mixture of things from their repository and from repoforge which makes me a little nervous. Doesn't seem to be an issue in practice.
There are also some 2.7/3.0 upgrade issues listed here:
I got a couple of errors running their 3.0.1 client against my master, which is 2.7.9:
[root at dynam-160 yum.repos.d]# puppet agent --test
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: Could not intern from pson: source '"#<Puppet::Node:0xb7' not in PSON!
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://puppet/plugins
Info: Caching catalog for dynam-160.cs.iay.org.uk
Info: Applying configuration version '1353512270'
Finished catalog run in 0.53 seconds
[root at dynam-160 yum.repos.d]#
It appeared to have applied all my resource definitions correctly, however (I skipped the previous run where it did all that). I'm sure this would go away if I was prepared to upgrade the master as well.
How any of this might play into Repoforge's packaging guidelines I have no idea.
> Honestly, I don't even think it would run on RHEL4 due to various Ruby
> dependencies, and in any case, it's in the extended life cycle now, so I
> wouldn't call RHEL4 support a priority…
Personally, I agree 100% but again I don't know what Repoforge's versioning policies are.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4813 bytes
Desc: not available
More information about the users