[chef] Re: Re: Re: Re: Re: Re: Re: Re: Berksfile.lock commit in dev branches


Chronological Thread 
  • From: Torben Knerr < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Berksfile.lock commit in dev branches
  • Date: Tue, 17 Feb 2015 07:16:46 +0100

Yes, you can't update single cookbooks with that :-(

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" < "> >:
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 ;-)

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 :)

Cheers,

--
Xabier de Zuazo



Archive powered by MHonArc 2.6.16.

§