Issues getting the template/skeleton build working

[chef]

Issues getting the template/skeleton build working

[sethvargo]

You can either remove the dependency on preparation or you can uncomment the omnibus-software gem in the Gemfile.

[bsnape]

Hi @sethvargo thanks for the quick reply.

Uncommenting the dependencies on preparation and version-manifest still result in the 'permission denied' error described above.

The omnibus-software gem isn't in my Gemfile. I was more confused about it being referenced in an error message yet no gem with that name exists in Rubygems!

Anyway, I found my problem. I had a hunch it was because of OSX and I was right. To fix:

• comment out preparation and version-manifest dependencies in /config/projects/<project name>.rb.
• uncomment the line base_dir './local' in omnibus.rb
• update the install_dir in /config/projects/<project name>.rb to point to ./local/omnibus/build instead of /opt/<project name>

I can submit a PR with OSX/non-root build instructions in the README.md or Building on OSX.md if you'd like?

[sethvargo]

@bsnape are you trying to build locally on your mac?

Omnibus really isn't designed to be run as non-root, since most packages will require root permissions to install.

[bsnape]

@sethvargo yes, but only initially to get a feel for what Omnibus offers.

The plan is to make a basic CentOS RPM consisting of some RSpec tests for AWS infrastructure along with the required gems (no applications needed).

Really, we're trying to find a nice way (i.e. using Omnibus) to get around the gem dependency/updating hell for RHEL-based infrastructure.

These tests will then be executed by Sensu as part of our cloud infrastructure (AWS) monitoring.

Hopefully this is the right way to go!

[sethvargo]

@bsnape this is a good way to do some testing (I have a similar setup locally), but I'm not sure I see advantages in making these the "defaults" or a "supported" pathway. /cc @schisamo @yzl

[bsnape]

I'm not sure what you mean when you say "I'm not sure I see advantages in making these the "defaults" or a "supported" pathway." - please can you clarify?

[sethvargo]

@bsnape we don't support building "local" software definitions. Keep in mind that the install_dir value you choose is where the project will be installed on disk by everyone else. So, choosing ~/Desktop/foo will always install the software into ~/Desktop/foo. The local mode is there if you prefer not to share the cache and build artifacts with other omnibus projects. It's not designed to let you build packages on your personal computer for production.

You can use omnibus for the use case you've described, but you'll want to run it in CI - we use Jenkins - and then grab the produced artifact and publish it.

We (as the release engineering team) don't support building packages on your local machine. We package a Test Kitchen-based Virtual Build lab (instructions in the generated README) instead.

[bsnape]

Thanks for the clarification regarding the install_dir @sethvargo.

Yep, we intend to slot this in to our CD pipeline in this manner.

Using Test Kitchen is absolutely the way to go for us - I simply wanted to get the simplest possible thing working first and then iterate (rather than attempting to "do all the things" straight off the bat and get nowhere/not understand how the individual pieces - Omnibus, Test Kitchen, Berkshelf - fit together). We are a Puppet-house at my company so these tools are new to us but I'm sure we'll be fine.

Thanks again for the help.