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

[Torben Knerr < >]

There was https://tickets.opscode.com/browse/CHEF-4027 once, but it
seems it had not been migrated to the Github issues (at least I
couldn't find it there).

And what's so bad about referencing Git repos from a Berksfile?

It's much more explicit and transparent than overloading namespaces
globally by pointing to a different "source" location.

Cheers,
Torben

On Tue, Jan 6, 2015 at 9:38 PM, Noah Kantrowitz 
<
 >
 wrote:
>
> 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
>