[chef-dev] Re: omnitruck vs chef.json

Chronological Thread 
  • From: Lamont Granquist < >
  • To: Ryan Hass < >
  • Cc: " " < >
  • Subject: [chef-dev] Re: omnitruck vs chef.json
  • Date: Sat, 12 Sep 2015 23:46:51 -0700

The platform.rb is all about remapping what comes in from install.sh onto the artifacts. The platform.json is all about what artifacts are are defined.

Its messy, but if anything the direction I'd like to go would be to move more stuff into platform.rb or into code and make the json file generated.

On 09/12/2015 03:59 PM, Ryan Hass wrote:
I encountered something today in my adventures to get an omnitruck instance which left me a little curious.

In the omnibus-chef repo, there is a chef.json which contains mappings of a given build of something to a set of corresponding platforms which that build should be used. For example, centos-6 maps here to centos 6 and 7.


However, omnitruck puts a little twist on all this by adding it's own mappings for various platforms:


This being said, why have the remappings in omnitruck at all? Why not have all the mappings defined in the json file and have the release scripts handle the result.

For example:

"build_os=fedora-22,machine_architecture=armv7l,role=oss-builder": [

I do realized I can just as well set the value to "el" in the chef.json. However, in my very specialized use case where CentOS is not a readily available option, it would make things easier to manage if the mappings were only managed in the chef.json (and chef-server.json, etc.).

If this notion makes sense to Chef as a whole, I don't mind writing up an RFE; but may just simply be unaware of something important in understanding the "why" for the way it works today.

-Ryan H.

Archive powered by MHonArc 2.6.16.