Feature #10540

Allow simplified configuration to upgrade older clients.

Added by Jo Rhett 7 months ago. Updated 4 months ago.

Status:Investigating Start date:11/03/2011
Priority:Normal Due date:11/18/2011
Assignee:- % Done:

50%
Category:-
Target version:2.7.x Estimated time:1.00 hour
Affected Puppet version: Branch:
Keywords:
Votes: 1

Description

we are having problems with incompatibility between older clients and newer configuration syntax. (in specific, user resource system attribute was added somewhere between 2.6.6 and 2.6.11)

It seems the right thing to do for older clients when they attach is to give them a very short manifest that immediately upgrades them. I’m trying to figure out how to do this. I want something like this at the top of site.pp

if $puppetversion == ‘2.6.6’ { class { upgradepuppet: } stop-parsing-here }

I’d rather avoid putting all the rest of site.pp inside an else statement if I can.

History

#1
Updated by Kelsey Hightower 6 months ago

  • Status changed from Unreviewed to Needs More Information

Thanks for reporting this issue. Can you provide the configuration syntax that is causing the problem for the nodes running “older” version of puppet? I would like to reproduce this on my setup.

Thanks

#2
Updated by Jo Rhett 6 months ago

user { 'cacti':
            ensure     => present,
            home       => '/local/home/cacti',
            system     => true,
            uid        => 499,
            gid        => 499,
            comment    => 'cacti',
            shell      => '/bin/bash',
            managehome => true,
    }

Older clients barf on the “system” parameter.

However, aside from puppet issues we have found numerous other upgrade-related issues. Patches that can’t be applied, scripts that won’t operate properly without other upgrade related issues. These aren’t puppet-related issues, but it really would be good if it was possible to use a facter value to produce a much shortened catalog used to achieve a specific upgrade.

From what I can tell, even just an “exit” I can use within a block would meet my needs.

#3
Updated by Kelsey Hightower 6 months ago

  • Assignee set to Kelsey Hightower

Jo,

Thanks for providing the update, I will be taking a look at this shortly.

#4
Updated by Kelsey Hightower 6 months ago

Now that I am thinking about this, can you use run stages to solve your problem?

What if you made a ‘puppet’ module, which was include by all your nodes, that ensures that all nodes run with a certain version of Puppet and any other required configurations. Then use puppet run stages to ensure that all the resources in your puppet module run first.

In site.pp

stage{'first': before => Stage['main']}

class {
  'puppet': stage => first;
}

node 'node.testing.com' {
  include puppet
}

Not sure if I’m on the right track with this, I just thought I would throw this out there.

#5
Updated by Kelsey Hightower 6 months ago

  • Due date set to 11/18/2011
  • Status changed from Needs More Information to Investigating
  • % Done changed from 0 to 50
  • Estimated time set to 1.00

#6
Updated by Jo Rhett 6 months ago

Run stage won’t work because puppet doesn’t re-execute itself between stages, per many other bugs ;–) It might upgrade itself in an upgrade stage, but it would continue running the current binary through to the next stage and fail.

#7
Updated by Michael Stahnke 4 months ago

  • Target version changed from 2.6.x to 2.7.x

2.6.x is closed. Moving to 2.7.x

#8
Updated by Kelsey Hightower 4 months ago

  • Assignee deleted (Kelsey Hightower)

Also available in: Atom PDF