[users] [Fwd: RPMforge/Repoforge and Puppet]

[Yury V. Zaytsev]

I only came across their repository after I sent you the original mail
earlier today, so I haven't tried it yet. My main concern would be
whether they end up putting everything in the same place: in the
"learning Puppet" VM, for example, they appear to drop everything
into /etc/puppetlabs/puppet instead of just /etc/puppet. 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!

Last time I looked at it, they were still doing something strange with
Puppet, but Facter packages were perfectly alright, and this was long
time ago, so things must have improved ever since.

I'd also note that their repository only includes Fedora, RHEL 5 and
RHEL 6; i.e., none of the older EL releases are covered. I don't know
how important that is these days (I happen to be on CentOS 5 and
CentOS 6 so it would be fine for me personally).

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...

[Ian Young]

Post by Yury V. Zaytsev

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 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.

Post by Yury V. Zaytsev
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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20121121/77877bc7/attachment.p7s>

[Yury V. Zaytsev]

Post by Ian Young
I just tried this with a random VM I wasn't using for anything else.

Thanks for sharing!

I see, so the major point is that PuppetLabs are offering 3.x already,
which to me looks like quite a big leap. Personally, I'd like to stick
to 2.7.x on my infrastructure for awhile, now that I have extremely
limited time for maintenance available...

Post by Ian Young
How any of this might play into Repoforge's packaging guidelines I have no idea.

Having that said, I think it makes sense for us to provide 2.7.x for
quite some time. Steve has just merged Tom's pull request in, so now
it's up to Dag to build it and it will become available at some point.

Post by Ian Young
Personally, I agree 100% but again I don't know what Repoforge's versioning policies are.

The policy is that whatever gets into extended life cycle is supported
on the best effort basis, i.e. we don't willfully break things, but
support for those platforms is not a priority.

[Ian Young]

Post by Yury V. Zaytsev
I see, so the major point is that PuppetLabs are offering 3.x already,
which to me looks like quite a big leap. Personally, I'd like to stick
to 2.7.x on my infrastructure for awhile, now that I have extremely
limited time for maintenance available?

I've only recently started with puppet, so I might flip the other way at least on the master. The bug I was concerned with is on the client side anyway, though, so having that fixed in the repoforge version would definitely be valuable.

Post by Yury V. Zaytsev

Post by Ian Young
How any of this might play into Repoforge's packaging guidelines I have no idea.

Having that said, I think it makes sense for us to provide 2.7.x for
quite some time.

That makes sense to me.

It's particularly true for CentOS 5, I think, because of the requirement to replace a core package (ruby) with a newer version to support puppet 3.x.

It might be more arguable for CentOS 6, where I believe the system version of ruby is more recent, but figuring that out sounds like it would be a lot more work.

Post by Yury V. Zaytsev
Steve has just merged Tom's pull request in, so now
it's up to Dag to build it and it will become available at some point.

Although I can't see the merge on github, I'm sure I am just not looking in the right place. Presumably it's happening in a git repository fork somewhere.

Some days are just too educational...

-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20121121/98a39d4d/attachment.p7s>

[Ian Young]

Post by Yury V. Zaytsev
I see, so the major point is that PuppetLabs are offering 3.x already,
which to me looks like quite a big leap. Personally, I'd like to stick
to 2.7.x on my infrastructure for awhile, now that I have extremely
limited time for maintenance available?

I've only recently started with puppet, so I might flip the other way at least on the master. The bug I was concerned with is on the client side anyway, though, so having that fixed in the repoforge version would definitely be valuable.

Post by Yury V. Zaytsev

Post by Ian Young
How any of this might play into Repoforge's packaging guidelines I have no idea.

Having that said, I think it makes sense for us to provide 2.7.x for
quite some time.

That makes sense to me.

It's particularly true for CentOS 5, I think, because of the requirement to replace a core package (ruby) with a newer version to support puppet 3.x.

It might be more arguable for CentOS 6, where I believe the system version of ruby is more recent, but figuring that out sounds like it would be a lot more work.

Post by Yury V. Zaytsev
Steve has just merged Tom's pull request in, so now
it's up to Dag to build it and it will become available at some point.

Although I can't see the merge on github, I'm sure I am just not looking in the right place. Presumably it's happening in a git repository fork somewhere.

Some days are just too educational...

-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20121121/98a39d4d/attachment-0002.p7s>

[Yury V. Zaytsev]

Post by Ian Young
I just tried this with a random VM I wasn't using for anything else.

Thanks for sharing!

I see, so the major point is that PuppetLabs are offering 3.x already,
which to me looks like quite a big leap. Personally, I'd like to stick
to 2.7.x on my infrastructure for awhile, now that I have extremely
limited time for maintenance available...

Post by Ian Young
How any of this might play into Repoforge's packaging guidelines I have no idea.

Having that said, I think it makes sense for us to provide 2.7.x for
quite some time. Steve has just merged Tom's pull request in, so now
it's up to Dag to build it and it will become available at some point.

Post by Ian Young
Personally, I agree 100% but again I don't know what Repoforge's versioning policies are.

The policy is that whatever gets into extended life cycle is supported
on the best effort basis, i.e. we don't willfully break things, but
support for those platforms is not a priority.

[Yury V. Zaytsev]

-------- Forwarded Message --------
From: Ian Young <ian at iay.org.uk>
To: yury at shurup.com
Subject: RPMforge/Repoforge and Puppet
Date: Wed, 21 Nov 2012 11:16:41 +0000

Hi,

I notice that you're the last person who updated the puppet package SPEC file in the repoforge/rpmforge repository:

https://github.com/repoforge/rpms/blob/master/specs/puppet/puppet.spec

I was wondering if you had any plans to update this to a newer version of puppet any time soon? I think it's up to something like 2.7.20 (up from 2.7.9) now, and it happens that there's a really irritating bug in versions before 2.7.10 (although apparently 2.7.10 had regressions of its own) that affects me and I suspect a number of other people:

http://projects.puppetlabs.com/issues/11414

The problem is in version checking the augeas libraries, which stopped working at 0.10.0 due I think to using string comparison instead of version comparison.

Obviously I could try and rebuild this package and roll it out to all of my machines myself, but it looks like there would be a fair bit of learning curve involved in that so if you were already planning on looking at it, it would save me a lot of time?

Cheers,

-- Ian

[Yury V. Zaytsev]

Hi Ian,

Post by Yury V. Zaytsev
I notice that you're the last person who updated the puppet package

I would like to update Puppet in RepoForge, but currently I lack time
and resources to do so.

Right now the version that is currently in is not as horribly broken as
it used to be the case for 0.25x series, so while updating to the latest
Puppet is desired, it's not a matter of life and death.

Besides, the repository that PuppetLabs is offering is getting better
and better over time, so I think eventually we should evaluate the
option of removing Puppet altogether and directing users to PuppetLabs
instead in the future.

Did you try PuppetLabs repository or you figured it doesn't solve your
problem?

[Tom G. Christensen]

Post by Yury V. Zaytsev
Hi Ian,

Post by Yury V. Zaytsev
I notice that you're the last person who updated the puppet package

I would like to update Puppet in RepoForge, but currently I lack time
and resources to do so.

I've maintained an updated version for our use, you're welcome to use it
if you like.

I just bumped it from 2.7.19 to 2.7.20 and sent a pull request:
https://github.com/repoforge/rpms/pull/217

It builds on el4,el5,el6 but has only been tested on el5,el6.

-tgc

[Yury V. Zaytsev]

Post by Tom G. Christensen
I've maintained an updated version for our use, you're welcome to use
it if you like.

Hi Tom,

Thanks a lot! Unfortunately, I'm unable to test it at the moment.

Denis do you have time and resources by any chance to test and merge
this pull request?

[Denis Fateyev]

Hello all,

Now, I am in Germany (Oldenburg, Lower Saxony), and a bit overwhelmed with
classes at the Uni.
I've got only a RHEL6 VM on my working notebook, doubt if it would be
enough for full testing.

---
wbr, Denis.

Post by Yury V. Zaytsev

Post by Tom G. Christensen
I've maintained an updated version for our use, you're welcome to use
it if you like.

Hi Tom,
Thanks a lot! Unfortunately, I'm unable to test it at the moment.
Denis do you have time and resources by any chance to test and merge
this pull request?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20121121/c5bc822c/attachment-0001.html>

[Ian Young]

Post by Yury V. Zaytsev
Besides, the repository that PuppetLabs is offering is getting better
and better over time, so I think eventually we should evaluate the
option of removing Puppet altogether and directing users to PuppetLabs
instead in the future.
Did you try PuppetLabs repository or you figured it doesn't solve your
problem?

I only came across their repository after I sent you the original mail earlier today, so I haven't tried it yet. My main concern would be whether they end up putting everything in the same place: in the "learning Puppet" VM, for example, they appear to drop everything into /etc/puppetlabs/puppet instead of just /etc/puppet. 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.

I'd also note that their repository only includes Fedora, RHEL 5 and RHEL 6; i.e., none of the older EL releases are covered. I don't know how important that is these days (I happen to be on CentOS 5 and CentOS 6 so it would be fine for me personally).

-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20121121/2a2a269a/attachment-0001.p7s>
-------------- next part --------------

[Yury V. Zaytsev]

I only came across their repository after I sent you the original mail
earlier today, so I haven't tried it yet. My main concern would be
whether they end up putting everything in the same place: in the
"learning Puppet" VM, for example, they appear to drop everything
into /etc/puppetlabs/puppet instead of just /etc/puppet. 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!

Last time I looked at it, they were still doing something strange with
Puppet, but Facter packages were perfectly alright, and this was long
time ago, so things must have improved ever since.

I'd also note that their repository only includes Fedora, RHEL 5 and
RHEL 6; i.e., none of the older EL releases are covered. I don't know
how important that is these days (I happen to be on CentOS 5 and
CentOS 6 so it would be fine for me personally).

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...

[Ian Young]

Post by Yury V. Zaytsev

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 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.

Post by Yury V. Zaytsev
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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20121121/77877bc7/attachment-0002.p7s>