How to prevent puppet clients from updating to version 3?

[Mister Guru]

I'm sending this email to start this thread, feel free to comment as appropriate. I'm going to assume that it's going to take a while for most people to actually realise that the puppet update may be giving them some issues, so, comments and suggestion please!

[llowder]

On Wednesday, October 3, 2012 9:37:01 AM UTC-5, Mister Guru wrote:

I'm sending this email to start this thread, feel free to comment as appropriate. I'm going to assume that it's going to take a while for most people to actually realise that the puppet update may be giving them some issues, so, comments and suggestion please!

Don't use ensure => latest.

Either just use installed, or a specific version, and then you can upgrade when you are ready to.

[Chad Huneycutt]

For yum-based updates, take a look at the yum versionlock plugin.
Works great here, although you have to specify the entire package name
that you want (I don't think just specifying puppet-2.7 will work).

debian-based distros support pinning, but haven't gotten that going yet.

- Chad

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.



--
Chad M. Huneycutt

[Jeffrey Watts]

This update will serve to educate them that using ensure => latest for critical packages like this in a production environment is not a good idea.  :)

Jeffrey.

[Aaron Grewell]

If you really want control over this you should build your own local repo mirror. That way you can be absolutely certain of what your systems will have access to. RHEL and friends come with all the tools to do this so it's not a major undertaking.

On Oct 3, 2012 7:37 AM, "Mister Guru" <mister...@gmail.com> wrote:

I'm sending this email to start this thread, feel free to comment as appropriate. I'm going to assume that it's going to take a while for most people to actually realise that the puppet update may be giving them some issues, so, comments and suggestion please!

--

[Dan White]

My $0.02:

I appended the following to /etc/yum.conf (RHEL 5 server)

exclude=puppet puppet-server ruby*

----- Original Message -----
I'm sending this email to start this thread, feel free to comment as appropriate. I'm going to assume that it's going to take a while for most people to actually realise that the puppet update may be giving them some issues, so, comments and suggestion please!

--
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

[Mister Guru]

I think a bit of learning, and burned fingers happened today - I'm searching my manifests for ensure => latest and getting rid of it!

[Mister Guru]

I agree, I learnt my lesson, but thankfully, it was in my testing environment - I've been writing shitty basic puppet code, and I'd just built a new puppet master, which was behaving very odd! That's when I noticed it was V3 - Good job I don;t run updates in my master - It also hit me that I don't actually manage the puppet client versions - I think I'm going to have to add that to my default node definition.

[Jeff McCune]

Even if you use ensure => installed, newly provisioned nodes will get
the latest available version at the time Puppet first runs, which will
cause issues unless you're also running a compatible Puppet master.

-Jeff

[Jo Rhett]

On Oct 4, 2012, at 12:39 PM, Jeff McCune wrote:

Either just use installed, or a specific version, and then you can upgrade

when you are ready to.

Even if you use ensure => installed, newly provisioned nodes will get
the latest available version at the time Puppet first runs, which will
cause issues unless you're also running a compatible Puppet master.

We have solved this here by only copying down the RPMs to a local repository after they have been tested. We've had too many puppet and facter versions cause major problems to take anything without a full testing cycle.

That said, it's a lot of work. I'd love to see the yum/etc resources updated to allow for < and <= versions.

-- 

Jo Rhett

Net Consonance : net philanthropy to improve open source and internet projects.

[llowder]

On Thursday, October 4, 2012 2:49:03 PM UTC-5, Jo wrote:

On Oct 4, 2012, at 12:39 PM, Jeff McCune wrote:

Either just use installed, or a specific version, and then you can upgrade

when you are ready to.

Even if you use ensure => installed, newly provisioned nodes will get
the latest available version at the time Puppet first runs, which will
cause issues unless you're also running a compatible Puppet master.

We have solved this here by only copying down the RPMs to a local repository after they have been tested. We've had too many puppet and facter versions cause major problems to take anything without a full testing cycle.

That said, it's a lot of work. I'd love to see the yum/etc resources updated to allow for < and <= versions.

Having that allowed as an option for all package providers would be nice.

You should open a ticket for that if you haven't already.

If you don't want to, let me know and I will open one.
 

[Jo Rhett]

There are a couple dozen open tickets regarding packages and repos to allow stuff like this. Probably more important would be to group all of those together and clean them up.