Omnitruck vs chef.json

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:

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.

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.