On 21 Nov 2012, at 14:53, "Yury V. Zaytsev" <[email protected]> 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: http://projects.puppetlabs.com/projects/puppet/wiki/Telly_Upgrade_Issues I got a couple of errors running their 3.0.1 client against my master, which is 2.7.9: [root@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@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. -- Ian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list [email protected] http://lists.repoforge.org/mailman/listinfo/users
