[chef] Re: in-house berks-api cookbook naming conflicts

[Noah Kantrowitz < >]

On Jan 6, 2015, at 11:35 AM, Koert Kuipers 
<
 >
 wrote:

> renaming internal cookbooks is not really an option, since it would also 
> involve renaming all attributes and it would all together create a giant 
> mess. 
> 
> it seems odd that i am forced to rename cookbook "x" just because someone 
> managed to upload an "x" to the central supermarket, even if the "x" on the 
> central supermarket is barely used.
> 
> it is also unclear to me how we can go about modifying an existing 
> cookbook. typically we do this and then a forced to temporarily use an 
> in-house version (until our pullreq is accepted and incorporated in a 
> release). for this we do not want to rename the cookbook since that is way 
> too disruptive and the change is only temporary. again this problem would 
> be solved if our inhouse supermarket could take precendence. with that 
> option not available i looked at other alternatives. one would be to 
> reference a git repo, since a git repo can take precendence over 
> supermarket, but everyone says that is bad practice. ok then i thought, 
> what if we modify cookbook "x" version 1.0.0 and publish it inhouse as 
> cookbook "x" version 1.0.0-mycompany, and pin the version we depend on? 
> again no luck, since chef and berks dont support such pre-release versions.

Indeed, the minimal support for complex version numbers is a bit painful 
here. There are a few major options:

The most robust solution is to stop using "source 
'https://supermarket.chef.io'" in your Berksfiles in favor of your own 
berks-api server pointed at your own Chef server and nothing else. This 
allows you to create an isolated universe where you control the namespace 
"entirely". The air quotes are because if you import any cookbooks from the 
community site, you may run in to issues where things depend on the community 
version of X instead of your incompatible version of X. This can be worked 
around at times, but you'll either have to not use community cookbooks as 
much, or eat the renaming pain on the community cookbook side eventually.

In cases where it is truly a temporary fork, I'll try really hard to keep the 
logic in a wrapper cookbook via chef-rewind or monkey patching but that isn't 
always going to be possible. If a fork has to happen, I'll generally set the 
version to 99.99.99 so it is unlikely to ever collide with a real release 
version, and then lock that version in the wrapper cookbook or environment 
(or both).

This in turn sometimes won't work if a ton of other cookbooks outside my 
control have version dependencies on the things I'm modifying. At this point 
a lot of people might be tempted to just leave the version number the same or 
bump it by 0.0.1 and upload to their Chef server, but here be dragons. When 
using non-git sources, Berks stores cookbooks by "name-version", not content 
hash, so you risk effectively a self-induced cache poisoning attack where 
some people might get your modified version in their cache and others might 
get the unmodified community version, and the only way you can really tell is 
when things break mysteriously despite using the same Berksfile.lock. If you 
must do a local fork with the same version number, definitely keep it in the 
Berksfile as a git reference so you don't clobber your cache.

If you don't like any of these options, sometimes discretion is the better 
part of valor and you should just wait for a new release. For cookbooks 
maintained by volunteers on their own time, offering to pay for some 
development time can greatly accelerate things but tread lightly as some devs 
might not like that idea. Good luck, you may need it :-)

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail