chef-client run fails to update rbenv due to failing git command about ruby_rbenv

[jkarnesPerfectCube]

I copied the box which was failing with chef-client 14.1.1 and confirmed the failure. I upgraded to chef-client 14.4.56-1 and the issue disappeared.

Thought this would help you track the issue down.

[josephholsten]

@jkarnesPerfectCube can you find out what version of git you're running? git fetch --prune-tags is valid from git 1.17 onward: https://git-scm.com/docs/git-fetch#git-fetch---prune-tags

It's also very strange that this is happening since it's the standard git resource that's adding the flag: https://github.com/sous-chefs/ruby_rbenv/blob/master/resources/system_install.rb#L49 I'm surprised that its default behaviour would explode.

[josephholsten]

ah, if the error went away with your upgrade to latest chef 14, then it probably was an upstream bug. I'm sorry about that! Do you think it's worth doing something to make the experience better in this sort of a failure? Or shall we just close this issue?

[jkarnesPerfectCube]

It depends on whether or not you intend for this cookbook to be compatible with that version of chef-client. Now that you're aware it happens, if you can reproduce it without external cookbooks, I would make a WARN to let others who potentially have the issue that it's known.

[josephholsten]

"reproduce it without external cookbooks"? I'm not sure what you mean. This is an incarnation of chef/chef#7233, introduced with chef/chef#7129 and fixed with chef/chef#7247.

You're suggesting we should do a version check of chef-client 14.1.1 <= x < 14.4.60 to trigger a warning that this is a know bug with a resolution of upgrading to chef-client 14.4.60+?

[jkarnesPerfectCube]

Yes.

I went through our recipes and cookbooks for about 15 minutes before checking resources, which took about another 20 minutes, and then after that checked the requirements and depedencies of this cookbook, then looked at the git cookbook, and finally - after almost an hour after I started - saw fit to raise an issue... only to find out that this issue was already known, solved, and yet un-warned.

Updating the chef-client version from the curl -L https://chef.io/chef/install.sh | sudo bash command includes a warning that updating without a pinned version is dangerous... so of course we pinned the version with the last chef-run that worked.

Our ops aren't as breakneck as some other shops, so we rarely need to update system state. This was an hour of a lead position's time to find the issue is already known but poorly reported.

[josephholsten]

I'm uncertain what you mean by "already known, solved, and yet un-warned", but it sounds worth avoiding in the future. Would you have a chance to draft the patch for this?

[jkarnesPerfectCube]

This is an incarnation of chef/chef#7233, introduced with chef/chef#7129 and fixed with chef/chef#7247.

To me, this indicates that the issue was known, but since everyone seems to update their chef-client somewhat more regularly than we did, they never ran into this particular problem once it was patched. It's unreasonable to expect every cookbook under the sun to alert the user when an upstream bug causes a failure, so I'm not certain if this cookbook is the proper place to inform the user of the error. Would it make more sense to have the WARN take place in the git cookbook? That would have avoided this issue as well I believe.

[jkarnesPerfectCube]

can you find out what version of git you're running? git fetch --prune-tags is valid from git 1.17 onward: https://git-scm.com/docs/git-fetch#git-fetch---prune-tags

git 2.7.4.
Git cookbook was 9.0.0

[josephholsten]

I think if there's going to be a warning, it's got to be here. The git resource is builtin to chef, so in order for people to get the version with the warning, they'd already have updated their chef-client.

[josephholsten]

Oops! I didn't mean --prune-tags is valid from git 1.17! I meant git 2.17.

[jkarnesPerfectCube]

Not only that, but any machine that is running chef-client in between those affected versions would also have to have a cookbook sync'd from whatever is provisioning which included a warning AND have it be the resource called from a recipe before another resource which may not have the warning.

I guess the best thing to do about this is to simply close it out since executing this WARN is likely not this cookbook's responsibility; however, it would be a nice little, "We have your back" type message.

I can look into drafting a patch if you're still interested in it.

[jkarnesPerfectCube]

@josephholsten Came back to this on the holiday and had a thought: Have you confirmed that this issue does not occur in Chef-Client versions between 13.x and 14.4.60? The readme for the cookbook says that the minimum version is 13+, and I am now wondering if that actually is the case.

[github-actions]

Marking stale due to inactivity. Remove stale label or comment or this will be closed in 7 days. Alternatively drop by the #sous-chefs channel on the Chef Community Slack and we'll be happy to help! Thanks, Sous-Chefs.

[damacus]

Closing due to inactivity.

If this is still an issue please reopen or open another issue. Alternatively drop by the #sous-chefs channel on the Chef Community Slack and we'll be happy to help!

Thanks,
Sous-Chefs