windows::unzip not ordering correctly?

[iaingblack]

Using Puppet 3.8.7 on windows and with future parsing enabled and manifest ordering. If I have a simple class like this;

  #===Software Artifact Unzip========
  file { "$tempfolder":
    ensure  => 'directory',
  } ->
  file { "$tempfolder\\software.zip":
    ensure  => 'present',
    source_permissions => ignore,
    source => "$fullInstallerLocation",
  } ->
  windows::unzip { "$tempfolder\\software.zip":
    destination => "$tempfolder",
    creates     => "$tempfolder\\myfile.txt",
    require     => File["$tempfolder\\software.zip"],
  }

Results in this execution order;

• Directory to hold zip contents created
• Zip copied to folder
• Zip is unzipped:

So, 1 -> 3 -> 2 instead of 1 -> 2 -> 3. I even put a requires in but it doesn't seem to help.

Any ideas?

Thanks!
Iain

[jonemo]

Hi @iaingblack, couple of questions to hopefully help with figuring this out:

1. Can you double check the ordering of that list of bullet points in your issue description, I think the second and third item are meant to be flipped.
2. Can you clarify what exactly you mean by "manifest ordering"? Do you mean the usage of -> or something else?
3. Can you confirm that this issue only occurs with future parsing (and not without future parsing)?
4. Would you mind posting the output of running puppet agent (or apply) with debug output?

[iaingblack]

Sorry, you are correct, a typo. This happens;

1. Directory to hold zip contents created (Should be 1)
2. Zip is unzipped (Should be 3)
3. Zip copied to folder (Should be 2)

Puppet run fails :)

What I mean by manifest ordering is that I set the puppet agent conf file to include this (https://puppet.com/blog/introducing-manifest-ordered-resources);

ordering = manifest

I'm also using future parser option in puppet.conf on a v3 agent so i'm future proofing anything I write today. Manifest ordering it supposed to be default on v4 agents so doing that too (and because i've had a little experience in chef and the puppet ordering is making me slightly insane!)

WIll test with future parsing/manifest ordering on and off. Will post outputs but probably be Monday i'm away this weekend. But thanks for the swift response!

Cheers
Iain

[jonemo]

Ok, thanks for these details, I have to admit this is the first time I heard about MOAR, I've clearly not kept up with the latest and greatest from Puppet v4...

I'm still not quite sure I understand this error fully. If you don't have the output of the run (and it fails), how do you know about the order in which these are executed?

[iaingblack]

No probs at all. I'm barely keeping up with this whole infrastructure as code concept!

I do have the error (work machine so cant just copy/paste, the concept is the same), but its not interesting. The unzip resource seems to be trying to unzip the file before the file (2) exists to unzip, ignorant of the desired order despite the requires in the next resource (3), and disobeying the manifest order flag (the order above is sensible). The error really is just that the file isn't there to unzip. Will post on Monday.

I do agree that the future parser or manifest ordering is causing the problems in some way. I'd do an exec and just not use the unzip resource but i'd really like to figure out a solution because its really nice for everyone.

Hoping not me making a mistake in my manifest, will test the options you gave over next few days.

Cheers
Iain

[jonemo]

To be honest, I don't see how this module could cause this error, this would be a Puppet language bug. Unless I'm missing something here, this manifest clearly enforces the order of operations. Whether or not manifest ordering is enabled should not affect the outcome because that should only kick in when you are not using require or ->.

I'm happy to dig in more if you provide an example manifest and log output. Without that I can't think of any way to help and would have to close this as #cantreproduce.

[tek0011]

I can confirm. On 3.7.3 and I have this same issue. It doesnt matter where I put the windows::unzip. I can even forcefully chain it. I get the same issue as original issue creator. It always runs out of order. Also using future parser, with ordering = manifest