Feature #7974

Stages should reload facts between runs

Added by James Fryman about 2 years ago. Updated 12 months ago.

Status:RejectedStart date:06/17/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:stages
Target version:-
Affected Puppet version: Branch:
Keywords:

Description

During a stage run, I might have some data in the form of a fact that will not be populated until future runs of puppet. Consider the below example. In this case, the logic in class bar will not be evaluated during the initial run of puppet until /etc/ROLE has been defined and populated on the machine.

Custom Fact:

 
Facter.add("role") do
  setcode do
    %x{/etc/ROLE -i}.chomp
   end
end

Puppet Code:


class stage {
  stage { ['pre', 'post']: }
  Stage['pre'] -> Stage['main'] -> Stage['post']
}
class foo {
  file { '/etc/ROLE':
    ensure  => file,
    content => 'FS',
  }
}
class bar {
  if $role == 'FS' { (do something ) }
}

Node Definition


node 'test' {
  class { 'foo':
    stage => 'pre',
  }

  include bar
}

History

#1 Updated by Daniel Pittman about 2 years ago

Feature #7974: Stages should reload facts between runs

During a stage run, I might have some data in the form of a fact that will not be populated until future runs of puppet. Consider the below example. In this case, the logic in class bar will not be evaluated during the initial run of puppet until /etc/ROLE has been defined and populated on the machine.

You are actually asking for a similar feature, “stages should be entirely separate catalog runs in Puppet”. :)

The catalog is static; stages are just a shorthand for ordering that you could otherwise express entirely by hand, by putting the right dependencies in place between the contained items in the relevant classes. (Which, indeed, is more or less what people did before stages came about. :)

Reloading facts between runs would actually be this:

  1. Puppet agent uploads facts, get the first stage catalog
  2. Puppet agent applies the first stage catalog
  3. Puppet agent uploads facts, gets the second stage catalog
  4. …repeat until you are done.

Part of this is because we interpolate the facts on the master, during compilation, before the catalog ever gets to the agent.

I don’t believe we want to support this multi-catalog model, and I don’t believe there is a mechanism for otherwise getting this right without fundamental architectural shifts – that, IMO, will render this request obsolete by doing the same thing a different way. :)

#2 Updated by Daniel Pittman about 2 years ago

  • Status changed from Unreviewed to Rejected

#3 Updated by eric sorenson 12 months ago

  • Category set to stages

Sweeping stage-related tickets.

This is interesting because the multiple-catalog model was proposed in conversation earlier as a desirable way to address this sort of thing.

Also available in: Atom PDF