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

[Koert Kuipers < >]

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.

On Fri, Jan 2, 2015 at 2:36 PM, Noah Kantrowitz < " target="_blank"> > wrote:

On Jan 2, 2015, at 11:00 AM, Koert Kuipers < "> > wrote:

> i just set up an in-house berks-api. its pretty neat!
>
> in Berksfile i now do:
> source "http://chef.my.organization:26200"
> source "https://supermarket.getchef.com"
>
> my only issue is that we have some inhouse cookbooks that have the same name as the ones on the supermarket. for example we have a kafka cookbook. i used to do:
> cookbook "kafka", path: "../kafka"
> but now that i have an inhouse berks-api i would like to just say:
> cookbook "kafka"
> and have it download from our chef server. unfortunately this means it downloads another cookbook from supermarket which has the same name and a newer version.
>
> i tried doing:
> cookbook "kafka", source: "http://chef.my.organization:26200"
> but that didn't work.
>
> any suggestions? i would like to avoid having to rename all our inhouse cookbooks.
> i also find this behaviour somewhat dangerous since i dont control supermarket. so if i have cookbook x and a week later someone adds cookbook x to supermarket without me being aware of it my cookbook could get suddenly clobbered.

Always name things 'mycompany-thing', assume a globally flat namespace. The alternative is to run _only_ off the internal berks API and the cross load stuff in to your chef server somewhat more manually when you want to pull in a community cookbook.

--Noah