Merging chef-sugar platform and
platform_family helpers, along with higher level helpers.
As a Cookbook Author, I want the Chef Sugar helpers added to Core, So that everyone can use them. As a Chef Developer, The platform_family abstraction is limiting, A set of helper functions provides better abstractions. As a Cookbook Author, Helper methods produce cleaner case statement, Which produces more readable and maintainable code. As a Chef Developer, Helper methods can provide cleaner abstractions, Which should produce less need to break APIs.
There's considerable argument over what a
platform_family should be, as evidenced by the
discussion over the amazon
platform_family issue. At the root of the problem seems to be
that every distro must belong to precisely one
platform_family while the classification of
different distros forms more of an inheritance hierarchy. The argument seems to be over at
which level of the hierarchy the
platform_family should apply.
Helper methods solve this problem by allowing a given distro to respond as true to different helper methods.
The chef-sugar helper methods have also found widespread adoption in the community and its time to pull them into core.
This RFC covers only the
platform_family helpers in chef-sugar along with
some other badly needed helpers. The
platform_version style of helpers (
are out of scope. The limiting of scope has no implications as to if we eventually want more
of chef-sugar into core or not (we certainly do want more of it in core), and is solely to limit
the scope of this work and the discussion. There do exist pieces of chef-sugar (like the
method_missing style of attribute syntax) that we explicitly do not want, and each piece of
chef-sugar needs to be assessed on its own merits.
We will pull in most of the Architecture, Platform and Platform Family helpers from chef-sugar
unmodified, along with the
kitchen? helpers. Since they have been
in widespread use, it is important to not modify their meaning.
The complete list of platform helpers is long, examples:
Note that this list deviates from the platform definitions in core chef, to eliminate ambiguity we will also add helpers which precisely match the field in core chef:
Additional helpers will also be added to fill out the complete list of platforms, which will match the fields used by core chef (matching the code in ohai).
Where there is a collision between
platform_family being named the same thing, and the platform_family
contains multiple distros, the platform version will be renamed:
This is driven mostly by the widespread adoption of the
debian? helper to mean "debian platform family".
For distros like "freebsd" where the platform, platform_family and os all match and there are no other derived classes
we shall use
freebsd? to refer to the platform.
Similarly we include the existing chef-sugar helpers:
Where the chef-sugar helper is different from the name of the
platform_family the name from ohai will also be added and
the full list from ohai data will be filled out.
These three helper will also be included:
docker? helper has already been merged as of Chef 12.11.18
In addition to the chef-sugar helpers, higher level helpers will be added:
rpm_based?-- this will include the
fedora_derived?-- this will include the
redhat_based?-- this will include the
solaris_based?-- this will include the
bsd_based?-- this will include the
Generally these helpers are designed to fit actual needs, not theoretical needs. As an example, there exist families of gentoo-based and arch-based systems but ohai does not support any of those other than the parent distro, so we do not define those helpers.
mac_os_x historically derives from BSD systems, including it in the
bsd_based? helper has no utility to anyone, so it is not
included. In general, these APIs are not derived from solely historical arguments (and explicitly do not match their wikipedia definitions).
fedora_derived? helper might be more usefully defined as RPM-based-distros-that-aren't-SuSE which is a useful category for systems
management, but not application management. For the actual historical overarching set of distros there is
rpm_based? and for the more
specific family of systems which are compatible with only RedHat-as-a-company there exists
redhat_based?. SuSE itself is significantly
different (redhat has never used YaST or zypper and never will).
redhat_based? helper is defined around the distro standards of the RedHat company itself. Recompiled RHEL platforms (OEL, Scientific)
are included along with straight forwards derivatives of fedora like pidora. Amazon is not included due to deviations amazon has made in
application support (different php, perl, etc versions and packaging, etc).
rpm_based? distro does not include AIX because while RPM has been ported to AIX, that O/S is not based around rpm, and again that is
a substantially less useful construct. Use
aix? to solve that case.
Once Chef 12.x has dropped off of the chef-sugar support matrix and all supported versions of chef-client have these helper methods in them, then the code for these helpers will be removed from chef-sugar. This should be a transparent change to users.
This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work.