Berksfile.lock commit in dev branches


#1

We’ve been having a discussion lately about whether to include Berksfile.lock in our dev branches for our cookbooks. Right now, I’ve only been including them in the stable branch. I’ve seen several other threads ( not on this list ) about this and opinions seem to be back and forth. Also, since the berks generators put Berksfile.lock into the .gitignore, it seems the opinion of Berks is to not include them.

I see the advantage of including them in the dev branches as providing an identical environment for anyone collaborating on the cookbook - but it seems like the Berksfile itself and the metadata.rb constraints should be enough to provide a ‘close enough’ environment.

What are the disadvantages of including the lock files?? What do you typically do for your cookbooks?


#2

Yo,

On Thu, Feb 12, 2015 at 9:25 AM, Hajducko, Steven <
Steven_Hajducko@intuit.com> wrote:

We’ve been having a discussion lately about whether to include
Berksfile.lock in our dev branches for our cookbooks. Right now, I’ve only
been including them in the stable branch. I’ve seen several other threads (
not on this list ) about this and opinions seem to be back and forth.
Also, since the berks generators put Berksfile.lock into the .gitignore, it
seems the opinion of Berks is to not include them.

I see the advantage of including them in the dev branches as providing
an identical environment for anyone collaborating on the cookbook - but it
seems like the Berksfile itself and the metadata.rb constraints should be
enough to provide a ‘close enough’ environment.

What are the disadvantages of including the lock files?​ What do you
typically do for your cookbooks?

Git ignoring the Berksfile lock, IME, relies exclusively on hosting your
own internal Supermarket or Chef Server Cookbook/Universe API for Berkshelf
to resolve against. In mega-repositories using Berksfile as an assembly
mechanism, I prefer to check in the lock file, too.

Relying on Berksfile constraints and metadata constraints and ad-hoc
resolution against the global Supermarket is a sure-fire road to pain. CI
can mitigate this somewhat and is great for uploading assets into the
previously mentioned behind-the-firewall Supermarkert/Universe
installations.

I currently use Solo and deploy a cookbooks directory via Git. You don’t
even need Berkshelf. Every installation has different requirements.

cheers,

–aj


#3

Hey,

What are the disadvantages of including the lock files?​ What do you typically do for your cookbooks?

This was a big debate for us too a few weeks ago. We’re using Berksflow so any application/environment cookbooks get the Berksfile.lock checked in. However, other cookbooks (like wrapper cookbooks) don’t. We version peg everything in metadata.rb. Either way (whether you check-in Berksfile.lock or not), there’s still no guarantee what you’re testing locally is 100% matching production (since production only looks at metadata.rb, unless you’ve version pegged an environment with something like Berksflow).

-Matt


#4

Hi Matt,

as you said, we are as well doing it only for the top-level cookbooks
(think of environment cookbooks but using metadata.rb instead of
environments to lock the dependency graph). Since we are using mostly
chef solo / zero having the Berksfile.lock checked in is enough.

I also experimented with generating / dynamically reading metadata.rb
entries from the Berksfile.lock for chef client / server use, but it
was just an experiment and YMMV:

Here’s an example “top-level cookbook”:

And if you are using Vagrant you might be interested in this, too:

Last but not least, I believe that the new Policyfile mechanism tries
to solve the issues we have, but I have not tested it yet and so I
can’t speak of it…

Cheers,
Torben

On Wed, Feb 11, 2015 at 9:43 PM, Matt Juszczak matt@atopia.net wrote:

Hey,

What are the disadvantages of including the lock files? What do you typically do for your cookbooks?

This was a big debate for us too a few weeks ago. We’re using Berksflow so any application/environment cookbooks get the Berksfile.lock checked in. However, other cookbooks (like wrapper cookbooks) don’t. We version peg everything in metadata.rb. Either way (whether you check-in Berksfile.lock or not), there’s still no guarantee what you’re testing locally is 100% matching production (since production only looks at metadata.rb, unless you’ve version pegged an environment with something like Berksflow).

-Matt


#5

Hi Chefs,
Please help!
I have upgraded my workstation (windows 2008 platform) from 3.6 to 4.0. And it seem that I have lost possibility to bootstrap nodes (windows platform as well).
WinRM on client side is configured fine and I can reach it form workstation as well. have tried it using powershell.
For bootstrap I am using command as follow:
knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]” -x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file ‘c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’

All I get is as follow: Waiting for remote response before bootstrap… And then time out no response…

I tried to install previous ChefDK 3.6 but it seems that it doesn’t work from newer version to older.
chef-client is still the same: c:\opscode\chef-repo>chef-client --version Chef: 12.0.3
Any ideas on how to fix this issue? Or I should fully delete ChefDK with all folders and set it up from the beginning?
Thank you in advance. Regards, Taras.


#6

Taras, what version of knife-windows are you running? The latest is 0.8.4.

Can you also get full logs from your knife-windows bootstrap attempt, e.g.
with –VV and share those?

Also, how did you configure authentication – are you using Negotiate on the
server, or have you configured basic auth?

-Adam

From: klum_tz@ukr.net [mailto:klum_tz@ukr.net]
Sent: Friday, February 13, 2015 6:44 AM
To: chef@lists.opscode.com
Subject: [chef] Can’t bootstrap windows node after upgrading to ChefDK
v4. (Please help! Windows platform)

Hi Chefs,

Please help!

I have upgraded my workstation (windows 2008 platform) from 3.6 to 4.0.

And it seem that I have lost possibility to bootstrap nodes (windows
platform as well).

WinRM on client side is configured fine and I can reach it form workstation
as well.

have tried it using powershell.

For bootstrap I am using command as follow:

knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]”
-x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file
’c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’

All I get is as follow:

Waiting for remote response before bootstrap… And then time
out no response…

I tried to install previous ChefDK 3.6 but it seems tha t it doesn’t work
from newer version to older.

chef-client is still the same:

c:\opscode\chef-repo>chef-client --version

Chef: 12.0.3

Any ideas on how to fix this issue? Or I should fully delete ChefDK with
all folders and set it up from the beginning?

Thank you in advance.

Regards,

Taras.


#7

Hi Adam,
Authentication on client side using WinRM is configured for basic auth. Sorry for the silly questions but how to find-out version of knife-windows?
Here is the same bootstrap command with -VV at the end:
PS C:\opscode\chef-repo> knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]” -x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file ‘c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’ -VV
Waiting for remote response before bootstrap…ERROR: No response received from remote node after 2.13 m inutes, giving up. ERROR: RuntimeError: Command execution failed. ‘-N’ is not recognized as an internal or external command, operable program or batch file.
And I see 1 more issue. “-N” - is not recognized… But I always used to use it for naming of adding nodes… :frowning:
Thank you in advance for helping me. Regards, Taras.

13 лютого 2015, 16:52:24, від Adam Edwards < adamed@getchef.com >:

Taras, what version of knife-windows are you running? The latest is 0.8.4. Can you also get full logs from your knife-windows bootstrap attempt, e.g. with –VV and share those? Also, how did you configure authentication – are you using Negotiate on the server, or have you configured basic auth? -Adam From: klum_tz@ukr.net [mailto: klum_tz@ukr.net ]
Sent: Friday, February 13, 2015 6:44 AM
To: chef@lists.opscode.com
Subject: [chef] Can’t bootstrap windows node after upgrading to ChefDK v4. (Please help! Windows platform) Hi Chefs, Please help! I have upgraded my workstation (windows 2008 platform) from 3.6 to 4.0. And it seem that I have lost possibility to bootstrap nodes (windows platform as well). WinRM on client side is configured fine and I can reach it form workstation as well. have tried it using powershell. For bootstrap I am using command as follow: knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]” -x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file ‘c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’ All I get is as follow: Waiting for remote response before bootstrap… And then time out no response… I tried to install previous ChefDK 3.6 but it seems tha t it doesn’t work from newer version to older. chef-client is still the same: c:\opscode\chef-repo>chef-client --version Chef: 12.0.3 Any ideas on how to fix this issue? Or I should fully delete ChefDK with all folders and set it up from the beginning? Thank you in advance. Regards, Taras.


#8

Use this command Taras:

Gem list knife-windows

It will show the version. And actually, 0.8.3 is the official latest (0.8.4
is a pre-release gem).

That output still seems abbreviated for –VV, but let’s first see the gem
version before digging there.

-Adam

From: klum_tz@ukr.net [mailto:klum_tz@ukr.net]
Sent: Friday, February 13, 2015 8:27 AM
To: adamed@getchef.com
Cc: chef@lists.opscode.com
Subject: Re [2]: Can’t bootstrap windows node after upgrading to ChefDK
v4. (Please help! Windows platform)

Hi Adam,

Authentication on client side using WinRM is configured for basic auth.

Sorry for the silly questions but how to find-out version of knife-windows?

Here is the same bootstrap command with -VV at the end:

PS C:\opscode\chef-repo> knife bootstrap windows winrm 172.25.3.201 -r
"role[eu1],recipe[push-jobs]" -x ‘Administrator’

-P ‘password’ -N ‘eu1-cstftp-norg’ --template-file
’c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’

-VV

Waiting for remote response before bootstrap…ERROR: No
response received from remote node after 2.13 m

inutes, giving up.

ERROR: RuntimeError: Command execution failed.

‘-N’ is not recognized as an internal or external command,

operable program or batch file.

And I see 1 more issue.

“-N” - is not recognized… But I always used to use it for naming of
adding nodes… :frowning:

Thank you in advance for helping me.

Regards,

Taras.

13 лютого 2015, 16:52:24, від Adam Edwards <adamed@getchef.com
adamed@getchef.com>:

Taras, what version of knife-windows are you running? The latest is 0.8.4.

Can you also get full logs from your knife-windows bootstrap attempt, e.g.
with –VV and share those?

Also, how did you configure authentication – are you using Negotiate on the
server, or have you configured basic auth?

-Adam

*From: *klum_tz@ukr.net [mailto:klum_tz@ukr.net]
Sent: Friday, February 13, 2015 6:44 AM
To: chef@lists.opscode.com
Subject: [chef] Can’t bootstrap windows node after upgrading to ChefDK
v4. (Please help! Windows platform)

Hi Chefs,

Please help!

I have upgraded my workstation (windows 2008 platform) from 3.6 to 4.0.

And it seem that I have lost possibility to bootstrap nodes (windows
platform as well).

WinRM on client side is configured fine and I can reach it form workstation
as well.

have tried it using powershell.

For bootstrap I am using command as follow:

knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]”
-x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file
’c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’

All I get is as follow:

Waiting for remote response before bootstrap… And then time
out no response…

I tried to install previous ChefDK 3.6 but it seems tha t it doesn’t work
from newer version to older.

chef-client is still the same:

c:\opscode\chef-repo>chef-client --version

Chef: 12.0.3

Any ideas on how to fix this issue? Or I should fully delete ChefDK with
all folders and set it up from the beginning?

Thank you in advance.

Regards,

Taras.


#9

Hi Adam,
Here what I have,
PS C:\opscode\chef-repo> Gem list knife-windows
*** LOCAL GEMS ***
knife-windows (0.8.2)
So actually after instaling ChefDK 4 I haven’t got latest gems version? How should I update everything up to date with all gems etc?
Thank you for replying so quickly and your support.
Regards, Taras.
13 лютого 2015, 19:15:37, від Adam Edwards < adamed@getchef.com >:

Use this command Taras: Gem list knife-windows It will show the version. And actually, 0.8.3 is the official latest (0.8.4 is a pre-release gem). That output still seems abbreviated for –VV, but let’s first see the gem version before digging there. -Adam From: klum_tz@ukr.net [mailto: klum_tz@ukr.net ]
Sent: Friday, February 13, 2015 8:27 AM
To: adamed@getchef.com
Cc: chef@lists.opscode.com
Subject: Re [2]: Can’t bootstrap windows node after upgrading to ChefDK v4. (Please help! Windows platform) Hi Adam, Authentication on client side using WinRM is configured for basic auth. Sorry for the silly questions but how to find-out version of knife-windows? Here is the same bootstrap command with -VV at the end: PS C:\opscode\chef-repo> knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]” -x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file ‘c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’ -VV Waiting for remote response before bootstrap…ERROR: No response received from remote node after 2.13 m inutes, giving up. ERROR: RuntimeError: Command execution failed. ‘-N’ is not recognized as an internal or external command, operable program or batch file. And I see 1 more issue. “-N” - is not recognized… But I always used to use it for naming of adding nodes… :frowning: Thank you in advance for helping me. Regards, Taras. 13 лютого 2015, 16:52:24, від Adam Edwards < adamed@getchef.com >: Taras, what version of knife-windows are you running? The latest is 0.8.4. Can you also get full logs from your knife-windows bootstrap attempt, e.g. with –VV and share those? Also, how did you configure authentication – are you using Negotiate on the server, or have you configured basic auth? -Adam From: klum_tz@ukr.net [mailto: klum_tz@ukr.net ]
Sent: Friday, February 13, 2015 6:44 AM
To: chef@lists.opscode.com
Subject: [chef] Can’t bootstrap windows node after upgrading to ChefDK v4. (Please help! Windows platform) Hi Chefs, Please help! I have upgraded my workstation (windows 2008 platform) from 3.6 to 4.0. And it seem that I have lost possibility to bootstrap nodes (windows platform as well). WinRM on client side is configured fine and I can reach it form workstation as well. have tried it using powershell. For bootstrap I am using command as follow: knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]” -x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file ‘c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’ All I get is as follow: Waiting for remote response before bootstrap… And then time out no response… I tried to install previous ChefDK 3.6 but it seems tha t it doesn’t work from newer version to older. chef-client is still the same: c:\opscode\chef-repo>chef-client --version Chef: 12.0.3 Any ideas on how to fix this issue? Or I should fully delete ChefDK with all folders and set it up from the beginning? Thank you in advance. Regards, Taras.


#10

The knife-windows gem is not currently part of ChefDK. Really, most of its
functionality should just be part of Chef Client (and thus part of ChefDK)
as you imply.

To update, just do the following:

Gem uninstall knife-windows

Gem install knife-windows

That should install 0.8.3. That said, it’s not clear to me that changes
between 0.8.2 and 0.8.3 will address the problem.

To simplify this, can you use the knife-winrm command, i.e.:

knife bootstrap windows winrm –m 172.25.3.201 –x ‘administrator’ -P
’password’ ipconfig

That should fail faster and be a narrower repro.

Note that there’s still a nasty bug in knife-windows during bootstrap that
is fixed in the pre-release, which you could install with gem install
knife-windows --pre. So if we get past the auth part, it may make sense for
you to upgrade to the pre-release.

Thanks.

-Adam

From: klum_tz@ukr.net [mailto:klum_tz@ukr.net]
Sent: Friday, February 13, 2015 9:33 AM
To: adamed@getchef.com
Cc: chef@lists.opscode.com
Subject: Re [2]: Re [2]: Can’t bootstrap windows node after upgrading to
ChefDK v4. (Please help! Windows platform)

Hi Adam,

Here what I have,

PS C:\opscode\chef-repo> Gem list knife-windows

*** LOCAL GEMS ***

knife-windows (0.8.2)

So actually after instaling ChefDK 4 I haven’t got latest gems version?

How should I update everything up to date with all gems etc?

Thank you for replying so quickly and your support.

Regards,

Taras.

13 лютого 2015, 19:15:37, від Adam Edwards <adamed@getchef.com
adamed@getchef.com>:

Use this command Taras:

Gem list knife-windows

It will show the version. And actually, 0.8.3 is the official latest (0.8.4
is a pre-release gem).

That output still seems abbreviated for –VV, but let’s first see the gem
version before digging there.

-Adam

*From: *klum_tz@ukr.net [mailto:klum_tz@ukr.net]
Sent: Friday, February 13, 2015 8:27 AM
To: adamed@getchef.com
Cc: chef@lists.opscode.com
Subject: Re [2]: Can’t bootstrap windows node after upgrading to ChefDK
v4. (Please help! Windows platform)

Hi Adam,

Authentication on client side using WinRM is configured for basic auth.

Sorry for the silly questions but how to find-out version of knife-windows?

Here is the same bootstrap command with -VV at the end:

PS C:\opscode\chef-repo> knife bootstrap windows winrm 172.25.3.201 -r
"role[eu1],recipe[push-jobs]" -x ‘Administrator’

-P ‘password’ -N ‘eu1-cstftp-norg’ --template-file
’c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’

-VV

Waiting for remote response before bootstrap…ERROR: No
response received from remote node after 2.13 m

inutes, giving up.

ERROR: RuntimeError: Command execution failed.

‘-N’ is not recognized as an internal or external command,

operable program or batch file.

And I see 1 more issue.

“-N” - is not recognized… But I always used to use it for naming of
adding nodes… :frowning:

Thank you in advance for helping me.

Regards,

Taras.

*13 лютого 2015, 16:52:24, від Adam Edwards <adamed@getchef.com
adamed@getchef.com>: *

Taras, what version of knife-windows are you running? The latest is 0.8.4.

Can you also get full logs from your knife-windows bootstrap attempt, e.g.
with –VV and share those?

Also, how did you configure authentication – are you using Negotiate on the
server, or have you configured basic auth?

-Adam

*From: *klum_tz@ukr.net [mailto:klum_tz@ukr.net]
Sent: Friday, February 13, 2015 6:44 AM
To: chef@lists.opscode.com
Subject: [chef] Can’t bootstrap windows node after upgrading to ChefDK
v4. (Please help! Windows platform)

Hi Chefs,

Please help!

I have upgraded my workstation (windows 2008 platform) from 3.6 to 4.0.

And it seem that I have lost possibility to bootstrap nodes (windows
platform as well).

WinRM on client side is configured fine and I can reach it form workstation
as well.

have tried it using powershell.

For bootstrap I am using command as follow:

knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]”
-x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file
’c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’

All I get is as follow:

Waiting for remote response before bootstrap… And then time
out no response…

I tried to install previous ChefDK 3.6 but it seems tha t it doesn’t work
from newer version to older.

chef-client is still the same:

c:\opscode\chef-repo>chef-client --version

Chef: 12.0.3

Any ideas on how to fix this issue? Or I should fully delete ChefDK with
all folders and set it up from the beginning?

Thank you in advance.

Regards,

Taras.


#11

Hi Adam,
No luck.
Here what I have got: PS C:\opscode\chef-repo> Gem uninstall knife-windows
You have requested to uninstall the gem: knife-windows-0.8.2
knife-ec2-0.10.0 depends on knife-windows (>= 0.8.2) knife-ec2-0.8.0 depends on knife-windows (>= 0.5.12) If you remove this gem, these dependencies will not be met. Continue with Uninstall? [yN] y Successfully uninstalled knife-windows-0.8.2
PS C:\opscode\chef-repo> Gem install knife-windows Fetching: knife-windows-0.8.3.gem (100%) Successfully installed knife-windows-0.8.3 Parsing documentation for knife-windows-0.8.3 Installing ri documentation for knife-windows-0.8.3 1 gem installed
PS C:\opscode\chef-repo> Gem list knife-windows
*** LOCAL GEMS ***
knife-windows (0.8.3)
PS C:\opscode\chef-repo> knife bootstrap windows winrm –m 172.25.3.201 –x ‘Administrator’ -P ‘password’ ipconfig
Waiting for remote response before bootstrap…ERROR: No response received from remote node after 2. 17 minutes, giving up. ERROR: URI::InvalidURIError: bad URI(is not URI?): http://ûm:5985/wsman
Windows IP Configuration

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : ec2.internal IPv4 Address. . . . . . . . . . . : 172.26.1.79 Subnet Mask . . . . . . . . . . . : 255.255.252.0 Default Gateway . . . . . . . . . : 172.26.0.1
Tunnel adapter isatap.ec2.internal:
Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : ec2.internal
Tunnel adapter Local Area Connection* 11:
Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . :
And here how I check connection to the box I am going to bootstrap from workstation: (powershell script)
$DBServerPassword = ‘password’ $ServerIP = ‘172.25.3.201’ $i = 0
$securepassword = ConvertTo-SecureString $DBServerPassword -AsPlainText -Force $creds = New-Object System.Management.Automation.PSCredential (“Administrator”, $securepassword)
while ($true) { $s = New-PSSession $serverIP -Credential $creds 2>$null if ($s -ne $null) { write-host “Successfully connected” -ForegroundColor Green Remove-PSSession $s break } $i = i + 1 "(Get-Date) Waiting for remote PS connection to $serverIP" if ($i -eq 10) { write-host “can’t connect to the host” -ForegroundColor Red break } }
And it (powershell) establishes connection immediatelly.
Should I install knife-windows -pre?
Thank you in advance.
Regards, Taras.
13 лютого 2015, 19:49:38, від Adam Edwards < adamed@getchef.com >:

The knife-windows gem is not currently part of ChefDK. Really, most of its functionality should just be part of Chef Client (and thus part of ChefDK) as you imply. To update, just do the following: Gem uninstall knife-windows Gem install knife-windows That should install 0.8.3. That said, it’s not clear to me that changes between 0.8.2 and 0.8.3 will address the problem. To simplify this, can you use the knife-winrm command, i.e.: knife bootstrap windows winrm –m 172.25.3.201 –x ‘administrator’ -P ‘password’ ipconfig That should fail faster and be a narrower repro. Note that there’s still a nasty bug in knife-windows during bootstrap that is fixed in the pre-release, which you could install with gem install knife-windows --pre. So if we get past the auth part, it may make sense for you to upgrade to the pre-release. Thanks. -Adam From: klum_tz@ukr.net [mailto: klum_tz@ukr.net ]
Sent: Friday, February 13, 2015 9:33 AM
To: adamed@getchef.com
Cc: chef@lists.opscode.com
Subject: Re [2]: Re [2]: Can’t bootstrap windows node after upgrading to ChefDK v4. (Please help! Windows platform) Hi Adam, Here what I have, PS C:\opscode\chef-repo> Gem list knife-windows *** LOCAL GEMS *** knife-windows (0.8.2) So actually after instaling ChefDK 4 I haven’t got latest gems version? How should I update everything up to date with all gems etc? Thank you for replying so quickly and your support. Regards, Taras. 13 лютого 2015, 19:15:37, від Adam Edwards < adamed@getchef.com >: Use this command Taras: Gem list knife-windows It will show the version. And actually, 0.8.3 is the official latest (0.8.4 is a pre-release gem). That output still seems abbreviated for –VV, but let’s first see the gem version before digging there. -Adam From: klum_tz@ukr.net [mailto: klum_tz@ukr.net ]
Sent: Friday, February 13, 2015 8:27 AM
To: adamed@getchef.com
Cc: chef@lists.opscode.com
Subject: Re [2]: Can’t bootstrap windows node after upgrading to ChefDK v4. (Please help! Windows platform) Hi Adam, Authentication on client side using WinRM is configured for basic auth. Sorry for the silly questions but how to find-out version of knife-windows? Here is the same bootstrap command with -VV at the end: PS C:\opscode\chef-repo> knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]” -x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file ‘c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’ -VV Waiting for remote response before bootstrap…ERROR: No response received from remote node after 2.13 m inutes, giving up. ERROR: RuntimeError: Command execution failed. ‘-N’ is not recognized as an internal or external command, operable program or batch file. And I see 1 more issue. “-N” - is not recognized… But I always used to use it for naming of adding nodes… :frowning: Thank you in advance for helping me. Regards, Taras. 13 лютого 2015, 16:52:24, від Adam Edwards < adamed@getchef.com >: Taras, what version of knife-windows are you running? The latest is 0.8.4. Can you also get full logs from your knife-windows bootstrap attempt, e.g. with –VV and share those? Also, how did you configure authentication – are you using Negotiate on the server, or have you configured basic auth? -Adam From: klum_tz@ukr.net [mailto: klum_tz@ukr.net ]
Sent: Friday, February 13, 2015 6:44 AM
To: chef@lists.opscode.com
Subject: [chef] Can’t bootstrap windows node after upgrading to ChefDK v4. (Please help! Windows platform) Hi Chefs, Please help! I have upgraded my workstation (windows 2008 platform) from 3.6 to 4.0. And it seem that I have lost possibility to bootstrap nodes (windows platform as well). WinRM on client side is configured fine and I can reach it form workstation as well. have tried it using powershell. For bootstrap I am using command as follow: knife bootstrap windows winrm 172.25.3.201 -r “role[eu1],recipe[push-jobs]” -x ‘Administrator’ -P ‘password’ -N ‘eu1-cstftp-norg’ --template-file ‘c:\opscode\chef-repo.chef\bootstrap\windows-chef-client-msi.erb’ All I get is as follow: Waiting for remote response before bootstrap… And then time out no response… I tried to install previous ChefDK 3.6 but it seems tha t it doesn’t work from newer version to older. chef-client is still the same: c:\opscode\chef-repo>chef-client --version Chef: 12.0.3 Any ideas on how to fix this issue? Or I should fully delete ChefDK with all folders and set it up from the beginning? Thank you in advance. Regards, Taras.


#12

We’re using an automated CI process to deliver cookbooks to our chef server
from source, that essentially runs berks upload. Having the Berksfile.lock
in source is important so the CI tool uploads the same version of deps
we’re developing against locally.

On Fri, Feb 13, 2015 at 5:28 AM, Torben Knerr mail@tknerr.de wrote:

Hi Matt,

as you said, we are as well doing it only for the top-level cookbooks
(think of environment cookbooks but using metadata.rb instead of
environments to lock the dependency graph). Since we are using mostly
chef solo / zero having the Berksfile.lock checked in is enough.

I also experimented with generating / dynamically reading metadata.rb
entries from the Berksfile.lock for chef client / server use, but it
was just an experiment and YMMV:
https://gist.github.com/tknerr/4e3236d00ceba917abea

Here’s an example “top-level cookbook”:
https://github.com/tknerr/sample-toplevel-cookbook

And if you are using Vagrant you might be interested in this, too:
https://github.com/tknerr/vagrant-toplevel-cookbooks

Last but not least, I believe that the new Policyfile mechanism tries
to solve the issues we have, but I have not tested it yet and so I
can’t speak of it…

Cheers,
Torben

On Wed, Feb 11, 2015 at 9:43 PM, Matt Juszczak matt@atopia.net wrote:

Hey,

What are the disadvantages of including the lock files? What do you
typically do for your cookbooks?

This was a big debate for us too a few weeks ago. We’re using Berksflow
so any application/environment cookbooks get the Berksfile.lock checked in.
However, other cookbooks (like wrapper cookbooks) don’t. We version peg
everything in metadata.rb. Either way (whether you check-in
Berksfile.lock or not), there’s still no guarantee what you’re testing
locally is 100% matching production (since production only looks at
metadata.rb, unless you’ve version pegged an environment with something
like Berksflow).

-Matt


#13

Hi tknerr,

On Fri, Feb 13, 2015 at 02:28:26PM +0100, Torben Knerr wrote:

as you said, we are as well doing it only for the top-level cookbooks
(think of environment cookbooks but using metadata.rb instead of
environments to lock the dependency graph). Since we are using mostly
chef solo / zero having the Berksfile.lock checked in is enough.

I also experimented with generating / dynamically reading metadata.rb
entries from the Berksfile.lock for chef client / server use, but it
was just an experiment and YMMV:
https://gist.github.com/tknerr/4e3236d00ceba917abea

We are currently using a similar solution to upload our “environment” cookbooks
to Chef Server and read the Berksfile.lock. Here is an example:

But this kind of solutions are too tricky :-S


Xabier de Zuazo


#14

Hi Xabier,

interesting to know. Yes, it’s indeed a bit hacky and uncommon an so
on… I would probably do it that way if I were using Chef Server, but
for Chef Solo / Zero having the Berksfile.lock checked in is
fortunately enough.

So do you use environments for environments then?

Cheers,
Torben

On Sat, Feb 14, 2015 at 9:35 AM, Xabier de Zuazo xabier@onddo.com wrote:

Hi tknerr,

On Fri, Feb 13, 2015 at 02:28:26PM +0100, Torben Knerr wrote:

as you said, we are as well doing it only for the top-level cookbooks
(think of environment cookbooks but using metadata.rb instead of
environments to lock the dependency graph). Since we are using mostly
chef solo / zero having the Berksfile.lock checked in is enough.

I also experimented with generating / dynamically reading metadata.rb
entries from the Berksfile.lock for chef client / server use, but it
was just an experiment and YMMV:
https://gist.github.com/tknerr/4e3236d00ceba917abea

We are currently using a similar solution to upload our “environment” cookbooks
to Chef Server and read the Berksfile.lock. Here is an example:

https://gist.github.com/zuazo/44308e89328ffb665ae1

But this kind of solutions are too tricky :-S


Xabier de Zuazo


#15

Hi Tobern,

On Sun, Feb 15, 2015 at 09:52:42AM +0100, Torben Knerr wrote:

interesting to know. Yes, it’s indeed a bit hacky and uncommon an so
on… I would probably do it that way if I were using Chef Server, but
for Chef Solo / Zero having the Berksfile.lock checked in is
fortunately enough.

Yes, I loved your approach and try to use it instead of mine. But I ran into
the problem that Berkshelf reads the Berksfile.lock to generate the
Berksfile.lock and berks update did not work properly.

So do you use environments for environments then?

Yes, sounds weird :smiley:

Cheers,


Xabier de Zuazo


#16

Hi Xabier,

yes, I believe I had the berks update problem too. Removing the
Berksfile.lock before running berks update helped, but that’s not
nice either. At this point I stopped the experiment since I have
mostly chef solo / zero requirements and so this was a problem I don’t
have to solve now :wink:

Btw: one thing I did differently by intent was to use plain ruby regex
for parsing the Berksfile.lock, as I was not sure whether berkshelf
API is present wherever the metadata.rb is evaluated. But as you have
shown it seems to work on chef client / server that way too…

Cheers,
Torben

On Mon, Feb 16, 2015 at 12:47 AM, Xabier de Zuazo xabier@onddo.com wrote:

Hi Tobern,

On Sun, Feb 15, 2015 at 09:52:42AM +0100, Torben Knerr wrote:

interesting to know. Yes, it’s indeed a bit hacky and uncommon an so
on… I would probably do it that way if I were using Chef Server, but
for Chef Solo / Zero having the Berksfile.lock checked in is
fortunately enough.

Yes, I loved your approach and try to use it instead of mine. But I ran into
the problem that Berkshelf reads the Berksfile.lock to generate the
Berksfile.lock and berks update did not work properly.

So do you use environments for environments then?

Yes, sounds weird :smiley:

Cheers,


Xabier de Zuazo


#17

Hi Torben,

On Mon, Feb 16, 2015 at 07:27:59AM +0100, Torben Knerr wrote:

yes, I believe I had the berks update problem too. Removing the
Berksfile.lock before running berks update helped, but that’s not
nice either. At this point I stopped the experiment since I have
mostly chef solo / zero requirements and so this was a problem I don’t
have to solve now :wink:

But AFAIK removing the Berksfile.lock I’m forced to update all the cookbooks at
the same time. I can not do something like the following:

$ berks update mysql

Btw: one thing I did differently by intent was to use plain ruby regex
for parsing the Berksfile.lock, as I was not sure whether berkshelf
API is present wherever the metadata.rb is evaluated. But as you have
shown it seems to work on chef client / server that way too…

Chef Server does not parse the metadata.rb and I have a Gemfile in my
Environment Cookbooks with the gem. Moreover ChefDK already comes with
berkshelf. In the few cases where it is not available, I show an error with
the installation instructions.

Still, if I’m honest, I did not think about it until I saw your solution.

Anyway, If that gives me problems in the future, I’ll replace it by your code,
which is also a good solution :slight_smile:

Cheers,


Xabier de Zuazo


#18

Yes, you can’t update single cookbooks with that :frowning:

I know that berkshelf is included in the ChefDK, but I believe it’s not
included in the omnibus chef client. So not sure if that plays well
together, but it should as chef client only looks at the generated
metadata.json, right?

Cheers, Torben
Am 17.02.2015 06:59 schrieb “Xabier de Zuazo” xabier@onddo.com:

Hi Torben,

On Mon, Feb 16, 2015 at 07:27:59AM +0100, Torben Knerr wrote:

yes, I believe I had the berks update problem too. Removing the
Berksfile.lock before running berks update helped, but that’s not
nice either. At this point I stopped the experiment since I have
mostly chef solo / zero requirements and so this was a problem I don’t
have to solve now :wink:

But AFAIK removing the Berksfile.lock I’m forced to update all the
cookbooks at
the same time. I can not do something like the following:

$ berks update mysql

Btw: one thing I did differently by intent was to use plain ruby regex
for parsing the Berksfile.lock, as I was not sure whether berkshelf
API is present wherever the metadata.rb is evaluated. But as you have
shown it seems to work on chef client / server that way too…

Chef Server does not parse the metadata.rb and I have a Gemfile in my
Environment Cookbooks with the gem. Moreover ChefDK already comes with
berkshelf. In the few cases where it is not available, I show an error with
the installation instructions.

Still, if I’m honest, I did not think about it until I saw your solution.

Anyway, If that gives me problems in the future, I’ll replace it by your
code,
which is also a good solution :slight_smile:

Cheers,


Xabier de Zuazo


#19

Ohai Torben!

On Tue, Feb 17, 2015 at 07:16:46AM +0100, Torben Knerr wrote:

[…]
I know that berkshelf is included in the ChefDK, but I believe it’s not
included in the omnibus chef client. So not sure if that plays well
together, but it should as chef client only looks at the generated
metadata.json, right?

That’s a good point, as you say omnibus chef-client does not include berkshelf.

CMIIW but I think chef-client ignores all the metadata files. It uses the
metadata field in the JSON data returned by the Chef Server. This metadata
contains the temporal “metadata.json” file content generated in the knife/berks
upload process.

So, more or less yes, chef-client only looks at the “metadata.json”.

Cheers,


Xabier de Zuazo