We use a number of proprietary packages from HP, Oracle, and others that
are not publicly available. With atomic-penguin’s help, I have set up a
corporate repository.
The many cookbooks currently assume that you will load a proprietary
package using a local url rather than a private deb/rpm repository. I find
this a bit ugly and I frequently create my own versions w/ the minor change
that I install w/ yum against my corporate repo rather than installing
using the “source” method of the package resource. For example, I do this
for Oracle’s jdk, which isn’t available in a public rpm repository.
Dear chefs, do you prefer to use a url to load proprietary packages or to
use a corporate repository? What could be the pros and cons of using a
corporate repository?
Dear chefs, do you prefer to use a url to load proprietary packages or to use a corporate repository?
We, generally, use repos for our in house packages -- mostly deb's and gem's. The, IMO, makes it easier to pull in dependencies using "normal" tools (apt-get, etc).
We use fpm to package things into debs rather than compiling things on each individual boxes, as well.
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
On Thu, Nov 10, 2011 at 12:48 PM, Brian Akins brian@akins.org wrote:
On Nov 10, 2011, at 3:12 AM, Bryan Berry wrote:
Dear chefs, do you prefer to use a url to load proprietary packages or
to use a corporate repository?
We, generally, use repos for our in house packages -- mostly deb's and
gem's. The, IMO, makes it easier to pull in dependencies using "normal"
tools (apt-get, etc).
We use fpm to package things into debs rather than compiling things on
each individual boxes, as well.
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
We "group" things into repos, and have several repos. IE, we have one for nginx, one for project A, one for project B, etc. I'm not sure it's a great idea, but these packages come from different sources - some are ops built, some are vendor provided, some are dev provided, etc. We have only one "internal" gem repo. I never claimed to be consistent
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):
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?
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.
In such a shared cookbook, I would make the name an attribute with a default value in the cookbook's attributes/default.rb. Then the consumer of the cookbook can change that to whatever they want in a role.
Also, have you guys seen the work Heavy Water Software (Darrin and AJ) did on their new project pennyworth? It may be useful and relevant to your interests.
This allows us to mirror the files locally and specify the local
download site in a role, while using the cookbook without any
modifications.
Bingo! This is why when I write cookbooks I make the download location for 3rd party repositories or hosting sites an attribute.
