8000 Effortless: Using chef client with chocolatey resource fails · Issue #109 · chef/effortless · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Effortless: Using chef client with chocolatey resource fails #109

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
russellseymour opened this issue Jul 19, 2019 · 6 comments
Open

Effortless: Using chef client with chocolatey resource fails #109

russellseymour opened this issue Jul 19, 2019 · 6 comments
Labels
Type: Bug Does not work as expected.

Comments

@russellseymour
Copy link
Contributor

Description

I am trying to use the Effortless pattern to create a workstation cookbook for my Windows 10 machines. I am using the newly merged chef/scaffolding-chef-infra package which has support for Windows now.

The package only installs Chocolatey and then uses the chocolatey_package resource to install two applications:

  1. Visual Studio Code
  2. Firefox

When Habitat runs the package, Chocolatey is installed correctly and indeed the chocolatey_resource runs, but the following errors are thrown.

2019-07-19_16-08-55

workstation.default hook[init]:(HK):     Failures
workstation.default hook[init]:(HK):      - vscode (exited 1) - vscode not installed. An error occurred during installation:
workstation.default hook[init]:(HK):      Item has already been added. Key in dictionary: 'Path'  Key being added: 'PATH'
workstation.default hook[init]:(HK):     STDERR:
workstation.default hook[init]:(HK):     ---- End output of C:\ProgramData\chocolatey/bin/choco.exe install -y vscode ----
workstation.default hook[init]:(HK):     Ran C:\ProgramData\chocolatey/bin/choco.exe install -y vscode returned 1

Indeed the commands that have failed work correctly when run as is in an elevated PowerShell window:

mstsc_2019-07-19_16-10-16

In case the text in the image is too small to see the error is:

I did think that something strange was happening when chef-client was run in the bundled PowerSHell core, however I have installed PSCore on the machine and run the same commands and no errors are thrown.

I have seen something like this a few years ago when I wrote POSHChef. It was down to the way in which items are deserialised. If you use the built in PowerShell cmdlet ConvertFrom-JSON in which "Path" and "PATH" are both valid elements in JSON this same error will be thrown.

However if the [System.Web.Script.Serialization.JavaScriptSerializer]::DeserializeObject() is used then "Path" and "PATH" can be made to be the same thing, although it will not be merged. (https://github.com/POSHChef/POSHChef/blob/master/functions/Exported/ConvertFrom-JSONtoHashtable.ps1).

If VSCode (or any app) is installed manually then the chocolatey_resource correctly detects that the app is installed.

Chef Version

This is being installed into the package using stuartpreston/chef-client package as is version 14.11.21`.

Platform Version

Windows: 10 1903
Habitat: 0.82.0

Replication

To replicate this issue please download by my repo at https://github.com/russellseymour/effortless and build the habitat package.

Then on a Windows 10 machine (use a local one or one in Azure for example):

  • Install Habitat
  • Run a service
  • Habitat install the built package
  • Load the service

After the package has initialised it will run chef-client and the issues will be seen as above.

When I first ran this I was only installing Visual Studio Code so thought that it might be something to do with that package. To test this I added another one and it failed as well (as seen above). To try and fix VSCode I added /DontAddToPath as a paramater option to Chocolatey but this had no effect either.

Stacktrace

Stack trace is in a Gist - https://gist.github.com/russellseymour/55d71343c5d34cd6f891af37886df5ed
@lamont-granquist lamont-granquist transferred this issue from chef/chef Jul 29, 2019
@TheLunaticScripter
Copy link
Contributor

Hey @russellseymour thank you for opening this. We will take a look and see if we can figure out what is going on here.

@TheLunaticScripter TheLunaticScripter added the Bug Doesn't work as expected. label Jul 31, 2019
@sam1el
Copy link
Contributor
sam1el commented Aug 18, 2019 •
edited
Loading

I've have tried this myself. I get a 50/50 result if I pass the 'refreshenv' command which i believe has more to do with how quickly things run than the an actual failure. That aside, wouldn't this be expected behavior? It's always been my understanding that chef-client wont read env changes on the fly in the same run unless you pass those env variables in the resource blocks that follow explicitly. Even when running chocolatey outs 8000 ide of chef-client, you have to reload powershell or run refreshenv before many of the programs installed by it will run.

@Defilan
Copy link
Defilan commented Oct 22, 2019

I'm running into this same issue across multiple Hab projects I'm working on. If I have any cookbooks that used the Chocolatey resource, they will always fail unless I convert them to a clunky execute resource. Is there any idea why this might be failing?

@TheLunaticScripter
Copy link
Contributor

We don't know yet why this is happening but we are waiting on a officially built chef-client for Windows so we can do better testing.

@lbergnehr
Copy link

Had this error and it was due to us running this through cygwin, which shadows the path variable with its variable named PATH (all caps). Before running the chef client I modified the environment to have the variable named Path again and then it worked!

$path = $env:PATH
remove-item env:PATH
$env:Path = $path

@TheLunaticScripter
Copy link
Contributor

@lbergnehr 🤔 interesting I'll need to think on that one if that is the case then it may be something in the chef-client itself that needs to be changed. cc @robbkidd

@tas50 tas50 added Type: Bug Does not work as expected. and removed Bug Doesn't work as expected. labels May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Bug Does not work as expected.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@sam1el @lbergnehr @russellseymour @tas50 @Defilan @TheLunaticScripter
0