[chef] Re: omnibus thoughts

[Anton Baranov < >]

When i started working with omnibus, i were confused by the same reasons.

For our purposes we thinking about creating our own fork of omnibus ruby-gem and modifying it as we want.

Just omnibus is open-source project of OpsCode, and they don't provide any support for our problems. I think, that OpsCode doesn't have enough time for implementation of all of our requests.

-- 

With best regards, Anton Baranov.

среда, 4 сентября 2013 г. в 21:41, John E. Vincent (lusis) написал:

(Not sure the best place to post this but doing it via twitter was getting a bit long in the tooth. I figured this was as good a place as any)

So I've been using omnibus pretty heavily over the past week and I've started to feel some pain points that I'd like to get input on.

Omnibus is obviously very focused on the idea of building fat packages for Opscode's various products. Not a big deal and totally understandable. It feels like at this point though, omnibus has grown into a product in its own right and has a community entirely outside of Chef users (folks are packaging puppet this way, for instance). I feel like there's a bit of conflict in those two things.

Right now, the omnibus-software repo is the master source/fallback for all things. I haven't looked to see if this is hardcoded into omnibus itself or if I'm missing something simple to override that. The software definitions in omnibus-software are always going to be designed to be for building/packaging all the bits of a chef-server/chef-client package. They're carefully curated to ensure they all play nice with each other.

This is great for reuse/community as long as the omnibus-software repo versions of packages are what you need. But if they aren't, you have to start copying out individual software files into your own project. If you have multiple projects internally that you build with omnibus, you have to duplicate that effort across all the projects.

So I have a proposal that I think would at least help part of that (and leads to a bigger question):

- Extended the project DSL to support defining an alternate source at the project level as well as at the individual dependency level. Obviously the sane default here (and sane default for fallback) is the opscode omnibus-software repo. Something like this (in config/projects/foo.rb)

name 'foo'

master_source '<some git uri or even a remote tarball>, :branch => 'master'

dependency 'erlang', :source => '<http url or an alternate repository>'

dependency 'nginx' # checks local 'software' dir first -> checks 'master_source' -> checks opscode upstream

This would allow me to reuse common components internally when other folks want to build custom packages using OUR known good configuration/combination.

The questions are if opscode would merge something like this functionality being that omnibus is so sensitive to the needs of building chef packages first and foremost? I read something like this:

"The first version of this project used Opscode's tool, but they don't seem to take pull requests, so I enhanced bernd's superb fpm-cookery to create Omnibus packages, and switched this project to use it." (from here: https://github.com/andytinycat/puppet-omnibus/blob/master/README.md)

And it gives me pause. As I said, I understand that omnibus exists to support opscode and that is the primary driver. I'm just wondering if this is something that others would value?