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

[Lamont Granquist < >]

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.
>
> https://github.com/chef/omnibus-chef/blob/master/jenkins/chef.json#L16-L27
>
> However, omnitruck puts a little twist on all this by adding it's own 
> mappings for various platforms:
>
> https://github.com/chef/opscode-omnitruck/blob/master/platforms.rb#L40-L48
>
> 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": [
>         [
>             "fedora",
>             "22",
>             "armv7l"
>         ],
>         [
>             "suse",
>             "13.2",
>             "armv7l"
>         ]
>     ]
>
>
>
> 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.