[chef] Re: Re: Re: a Cookbook pattern, the "corporate" repository for proprietary packages

[Zac Stevens < >]

Hiya,

On Thu, Nov 10, 2011 at 11:51 AM, Bryan Berry 
<
 >
 wrote:
> I think we need a common practice for this. It would be useful for me and
> you if we used the same name for our respective corporate repos. That way we
> can more easily reuse each other's recipes. I think "corporate" fits well ;)

Perhaps I'm missing something, but I can't see the benefit of using
the same name for our internal package repositories.

At $WORK, we have a cookbook that configures the appropriate mirrors
and repositories on a node.  After that's done, yum is responsible for
locating the packages specified in other cookbooks.  Those other
cookbooks shouldn't know (or care) about the name or URL of the
repository containing the packages.

For cookbooks that need to grab a file (rather than a package), I make
the download site an attribute.  A simple example can be seen here
(with a terrible attribute name, which I will be changing before
release):

https://github.com/zts/logstash-cookbook/commit/ccd56b36eff11c11bb859633fca9c575db67852f

This allows us to mirror the files locally and specify the local
download site in a role, while using the cookbook without any
modifications.

I'm really interested in ways to make cookbooks more readily reusable
"out of the box", so I love that you're raising the subject.  Could
you expand a little on the benefits of consistent repo naming?

Thanks,


Zac