Partial change from a puppet run

[David Evans]

Hi,

I notice that when I provision a host and puppet runs for the first time that it does not deliver all the change necessary for the next puppet run to be 'quiet'.  In fact it can take several runs before the host is up-to-date.  I have three concerns around this:

1. If I am spinning up a virtual host there may be a user requirement to start using it immediately - whereas it may take 90 minutes or more for puppet to complete (with 30 minute frequency of runs).
   
2. Is this behavior symptomatic of badly written puppet code?
   
3. I'm worried about a change that is partially delivered on a live system (post provisioning) - a host that is in a good state before and after a change may be in an unusable with part of the change applied.
   

I'd like to know if there is a way that I can specify that a puppet run should iterate until all the available change has been applied?  Or is there something I'm missing in my code to prevent this happening?

Thanks in advance for any assistance.

Regards,

David

PS, my environment is Satellite 6.0 and Puppet 3.6.2

[jcbollinger]

On Friday, April 24, 2015 at 9:35:12 AM UTC-5, David Evans wrote:

Hi,

I notice that when I provision a host and puppet runs for the first time that it does not deliver all the change necessary for the next puppet run to be 'quiet'.  In fact it can take several runs before the host is up-to-date.  I have three concerns around this:

1. If I am spinning up a virtual host there may be a user requirement to start using it immediately - whereas it may take 90 minutes or more for puppet to complete (with 30 minute frequency of runs).

You can always run the agent manually to avoid the 30-minute gap between runs.

 

2. Is this behavior symptomatic of badly written puppet code?

Yes.  There may be other contributing factors, but certainly if more than two runs are required then one of the problems is badly written Puppet code.

 

3. I'm worried about a change that is partially delivered on a live system (post provisioning) - a host that is in a good state before and after a change may be in an unusable with part of the change applied.

That is a reasonable concern.  It is a good reason to test your manifest and data changes in a QA environment before applying them to production machines.

 

I'd like to know if there is a way that I can specify that a puppet run should iterate until all the available change has been applied?

It wouldn't be too hard to write a script around something like 'puppet agent --no-daemonize --detailed-exitcodes' to achieve that behavior.

 

 Or is there something I'm missing in my code to prevent this happening?

There is.  Catalog application failures that can be resolved by iterating Puppet runs generally arise from failure to properly specify order-of-application relationships.  This is what the 'before' and 'after' metaparameters and the chaining arrows are for.  There are occasionally details that simply cannot be handled all in one run, but these are rare.  If you encounter one, then the way to resolve it is normally via your new-machine provisioning process.
 

John

[David Evans]

Hi John,

Thanks for this - very helpful.

It's good to know that properly written code will complete in one run and that will be my goal - I'm refactoring the code already and can see that it contains a lot of rookie errors.

I have also implemented a loop in our provisioning script to re-run puppet until all change is applied.  Theoretically that should not be necessary, but it may take a while to remove the existing problems and there's always the possibility that I, or a colleague, may introduce a new module that prevents all change being delivered in one run.

Thanks again,

David