[chef-dev] omnitruck vs chef.json

[Ryan Hass < >]

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.