Platform support policy proposal #21
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,96 @@ | ||
| # Chef Platform Support Policy | ||
|
|
||
| The purpose of this RFC is to clarify: | ||
|
|
||
| * What specific operating system platforms and platform versions are supported by the software produced by Chef Software, Inc. | ||
| * What is the meaning of "supported platform" | ||
|
|
||
| This RFC does *not* address "What is the product lifecycle of Chef Software, Inc.'s software". That is covered in a separate RFC | ||
|
|
||
| ## Chef Client | ||
|
|
||
| A Chef Client supported platform means: | ||
|
|
||
| * Omnitruck won't fail or go into Yolo mode when confronted with the platform | ||
| * The holy trinity of resources (package, service, template) works out of the box | ||
| * Ohai attributes for ```platform```, ```platform_family```, ```platform_version``` and ```kernel.machine``` are correct | ||
|
|
||
| Chef Client support implies Ohai support. | ||
|
There was a problem hiding this comment. As this document make this explicit instead of implicit, perhaps s/implies/requires/? |
||
|
|
||
| ### Tier 1 Support | ||
|
|
||
| Tier 1 supported platforms are those for which Chef builds native binary "Omnitruck" (full-stack installer) packages. For each platform, there is equipment in the CI pipeline to perform client verification tests on machines of that platform. | ||
|
|
||
| Platform | Versions | Architectures | Package Format | Built on | ||
|
There was a problem hiding this comment. Minor nitpick: This table is currently not 100% correct but it is where we ideally want to get to. Currently for centos, mac and ubuntu we perform builds on more that one version. There was a problem hiding this comment. I think it's important to capture what the desired state is, since it is an RFC, and then once adopted we put things in compliance. There are target platforms (e.g. Ubuntu 11.04) that are EOL that we should no longer build for, for example. |
||
| --- | --- | --- | --- | --- | ||
| CentOS | 5, 6, 7 | i386, x86_64 | rpm | RHEL 5 | ||
|
There was a problem hiding this comment. What about RHEL? Should we move to a place were we just refer to RHEL variants as EL and list what EL includes in one place? There was a problem hiding this comment. @schisamo I deliberately call El variants out separately because they have subtle differences (example: OEL with the UEK kernel by default) There was a problem hiding this comment. So then we need a row like: There was a problem hiding this comment. Yep, looks like I left it off by accident |
||
| FreeBSD | 9, 10 | i386, amd64 | pkg_add pkg | FreeBSD 9 | ||
|
There was a problem hiding this comment. Any chance FreeBSD support could be expanded for FreeBSD 8.X. I know Dyn had this compiling without issues and the 8.X series is still considered a production branch: http://www.freebsd.org/releases/ There was a problem hiding this comment. @tas50 I just can't see adding Tier 1 support and all the infrastructure involved to do that for something that's going to be end-of-life in 11 months. There was a problem hiding this comment. @juliandunn, surely in 11 months we will be discussing Chef 13 and dropping FreeBSD 8 support. I cannot measure the required infrastructure work, but considering that the EOL of other platform versions below is closer, I do not see this as crazy. All this taking into account that it already seems to work on FreeBSD 8. Of course, if the work involved is very large, it's not worth it. There was a problem hiding this comment. Its a zero sum game, and based on the size of the TODO list and the distros that we should support that are more modern and the lack of agility that we have in our CI infrastructure, I'm skeptical. If we did a stack ranking exercise of distro support things like better OEL testing (server), SmartOS, Debian (server), ArchLinux, Gentoo, etc are going to be ahead of it. I'd argue that SLES 10 is probably more important as well. And if we start from the top of the list and work down we're not going to hit FreeBSD 8 before its end of life. There was a problem hiding this comment. @lamont-granquist That's exactly my feeling. Our resources are limited and at some point we have to make some calls even if they are tough ones. |
||
| Mac OS X | 10.6, 10.7, 10.8, 10.9 | x86_64 | dmg | Mac OS 10.7 | ||
| Oracle Enterprise Linux | 5, 6, 7 | i386, x86_64 | rpm | RHEL 5 | ||
| Solaris | 9, 10, 11 | sparc, x86 (10 and 11 only) | shar | Solaris 9 | ||
|
There was a problem hiding this comment. Do we want to mention support (or lack thereof) for Solarish (i.e. illumos based) distributions? Examples would be OmniOS, SmartOS and OpenIndiana. I think we could manage at least Tier 2 for these with the Solaris packages if full support isn't feasible. There was a problem hiding this comment. @mivok Probably. I can add OmniOS as I'm reasonably familiar with the lifecycles. What would you suggest for SmartOS? And is OpenIndiana used by a lot of folks? There was a problem hiding this comment. fwiw I know Joyent has expressed a desire for SmartOS support and a willingness to contribute in the past. There was a problem hiding this comment. We've got a bunch of SmartOS support we've just never taken it across the finish line. There was a problem hiding this comment. Re: OpenIndiana - I don't think it's used by many people, but my familiarity has been mostly with OmniOS (for somewhat obvious reasons). If the level of effort is small (and it sounds like it is), we should support both OmniOS and SmartOS. There was a problem hiding this comment. PS: SmartMachines are in the same boat as Amazon Linux as a "cloud only" OS On Wed, Jul 23, 2014 at 10:39 AM, Mark Harrison notifications@github.com
There was a problem hiding this comment. And i'd prefer to see Amazon Linux and SmartOS builders/testers than OEL/RHEL testers for chef-client. Wasting a lot of effort on OEL and RHEL to learn that we already support those distros pretty well for just about zero code effort is a lot less useful than supporting SmartOS (where we don't have any omnibus build) or even Amazon (which is not a straight RHEL recompile and is where I'd expect to see weirdness crop up because... Amazon). There was a problem hiding this comment. Releng plans to have a tester for every platform we claim to support for Tier 1. This is our aspiration and ensures our gut feelings about Tier 1 support are actualities. There was a problem hiding this comment. So, if you're talking about having builders and testers for RHEL+OEL+CentOS for the client, then I disagree with that, you're just going to expand our support matrix and our stability for that one bug which will come in that is OEL specific this year. And that will come at the cost of effort that could be put to supporting some other platform that we don't support at all. There was a problem hiding this comment. Agree @lamont-granquist but alternatively we will not know if we break something on OEL until someone hits our breakage. I'm 👍 for having a tester for every platform we claim Tier 1 support. |
||
| Windows | 2003R2, 2008, 2008R2, 2012, 2012R2 | x86 and x86_64 | msi | Windows 2008R2 | ||
|
There was a problem hiding this comment. Formatting variance, you used |
||
| Ubuntu Linux | 10.04LTS, 12.04LTS, 14.04LTS | x86 and x86_64 | deb | Ubuntu 10.04LTS | ||
|
There was a problem hiding this comment. I would seriously like to have a conversation about our continued support of 32-bit builds, especially for newer OS. There was a problem hiding this comment. @sethvargo probably not something we need to "officially" support, but there's definitely 32-bit embedded devices that people run Chef on. There was a problem hiding this comment. @sethvargo we would also need to include in that conversation "building 64-bit Chef for Windows" because it does cause pain for customers over sysnative, calling the wrong system commands, etc. There was a problem hiding this comment. Yeah 64 bit support on Windows is a long pole. Some of the gems used by Chef are known not to work on 64 bit Ruby. We should have this conversation on a case by case basis. There was a problem hiding this comment. Probably don't need the |
||
|
|
||
| ### Tier 2 Support | ||
|
|
||
| Tier 2 supported platforms are those on which Omnitruck will serve packages, but those packages may not have been built on that OS variant. Additionally, we do no CVT on these platforms. | ||
|
There was a problem hiding this comment. The |
||
|
|
||
| * SUSE Linux Enterprise Server 10, 11 | ||
|
There was a problem hiding this comment. We have testers for SLES11, SLES10 is actually broken and we'd need to compile packages specifically for SLES10 since the EL5 binaries fail on SLES10 (ie. it would need to be tier 1). Based on the failure with SLES10, i think we need to maintain SLES11 testers. There was a problem hiding this comment. I guess I question the need to maintain the infrastructure for that and to treat SLES as Tier 1. Do we have enough SLES users to justify it? There was a problem hiding this comment. We definitely need to support SLES at Tier1. It's huge in Europe and in On Fri, Jul 25, 2014 at 1:06 AM, Julian C. Dunn notifications@github.com
|
||
| * Scientific Linux 5.x, 6.x and 7.x (i386 and x86-64) | ||
| * Debian Linux 6.x and 7.x | ||
|
There was a problem hiding this comment. Ah, yeah we currently have omnibus builders and testers for debian and need to maintain that. |
||
| * Gentoo Linux ***what versions?*** | ||
| * Arch Linux ***what versions?*** | ||
| * Fedora (current non-EOL revisions) | ||
| * OpenSUSE ***what versions?*** | ||
|
|
||
|
There was a problem hiding this comment. Can we get "SmartOS (rolling release)" into Tier 2? I'm more interested in ensuring that core resources work correctly on SmartOS than having the proper package delivered by Omnitruck. Joyent currently provides Rubygems builds for Chef Client, so maybe something could be worked out? There was a problem hiding this comment. I (and others besides @aglarond) would also love to see at least best-effort Tier 2 support for the SmartOS Illumos distro. It's one of the few cloud-specific OSes in the open source world, and lots of SmartOS users (including the parent company, Joyent) also use Chef heavily. I'd be more than happy to contribute some of my at-work time to getting this into Omnitruck for automatic knife bootstrapping, if someone from Chef can just point me in the right direction WRT contribution. Omnibus/Omnitruck is a bit daunting for a newcomer. CC/ @someara @sax as I've discussed this with both of them before more than once. Also note that a lot of the code we'd need for this would likely be cross-platform across all Illumos distros (OmniOS, SmartOS, OpenIndiana), and we might even be able to re-use some of the Omnibus build code for Solaris. So with the right guidance, we might be able to wrap this pretty quickly and get benefits across many platforms. Lastly, note the work that's happening here: https://github.com/sax/vagrant-smartos-zones |
||
| ### Not Supported | ||
|
|
||
| "Not supported" means there may be code in-tree, but we don't build for and test on those platforms. We will take patches that don't break any tier 1 or tier 2 platforms, but we have no way of testing these. | ||
|
There was a problem hiding this comment. I actually think its a bad idea to accept patches for ancient operating systems that we can't test on. Its solving a problem that we don't have for one, its going to break, and its very likely going to overly complicate building on the systems that we need to support. Scope creep in omnibus-chef is actually not cheap at all, its not just as simple as an #ifdef since in order to maintain omnibus-consistent builds we may have change how we build on RHEL7 in order to support AIX5.1 |
||
|
|
||
| * Solaris 8 | ||
| * AIX 5.1L | ||
| * FreeBSD 8 | ||
| * OpenBSD | ||
| * NetBSD | ||
| * Windows 2003, Windows 2000 | ||
|
There was a problem hiding this comment. For completeness, should XP and Vista be added to this list? There was a problem hiding this comment. Vista is ~2008r2, which we support, isn't it? There was a problem hiding this comment. Vista is 2008 R1. R2 is Windows 7 There was a problem hiding this comment. Yeah, but 2003r2, 2008, 2008r2 are all listed as tier1 support. This is another goofy edge case where I would bet money we can state we support it since we have to support the associated server SKUs but we don't because we don't explicitly test the client SKUs with ChefDK. |
||
| * RHEL/CentOS/Oracle/Scientific 4.x or older | ||
| * HP-UX | ||
| * Mac OS X 10.5, older, or anything ppc-based | ||
|
|
||
| ### Not Supported but We're Working On It | ||
|
|
||
| * AIX 6.1, 7.1 (ppc64) | ||
|
There was a problem hiding this comment. If this is a policy document, I don't think this should be a section. The policy is that this platform is supported, chef-client is just not matching that right now. |
||
|
|
||
| ### Not Supported but We'd be Open To It | ||
|
|
||
| * RHEL and SLES on POWER (ppc64) | ||
|
There was a problem hiding this comment. I don't think these need to be enumerated, if any new platform is proposed it can get its own RFC (or however we decided to handle updating long-lived RFCs over time). There was a problem hiding this comment. I enumerated them specifically just so that non-technical people (sales, consulting for example) can look at the list and at a glance tell a customer if something is supported or not. |
||
| * RHEL on System/z (would have to think long and hard though, how would we build clients?) | ||
|
|
||
| ## Chef Server | ||
|
|
||
| Includes any of the add-ons (webui2/manage, push, etc.) | ||
|
|
||
| ### Supported | ||
|
|
||
| * Ubuntu (which versions?) | ||
|
There was a problem hiding this comment.
There was a problem hiding this comment. https://wiki.ubuntu.com/LTS?action=AttachFile&do=get&target=ubuntu-release-cycle-2.png We should drop 11.04 if Canonical isn't supporting it. There was a problem hiding this comment. Agreed, there is no reason we should be building for vendor EOL'd operating systems IMO. |
||
| * RHEL 5.x and 6.x | ||
| * CentOS 5.x and 6.x | ||
| * Oracle 5.x and 6.x | ||
|
There was a problem hiding this comment. I know it's not officially supported, but we are installing OSC servers on Debian Wheezy platforms with no apparent problems. In fact, we use your chef-server cookbook. There was a problem hiding this comment. Based on bug reports it clearly seems like Debian should be Tier 1 and needs a tester to catch regressions. There was a problem hiding this comment. RHEL/CentOS/OEL 7. x is also missing |
||
|
|
||
| ### Unsupported | ||
|
|
||
| * Any other Linux or UNIX distributions | ||
|
There was a problem hiding this comment. As a very non-exhaustive list, I don't know if this is needed. |
||
| * Windows | ||
|
|
||
| ## ChefDK | ||
|
|
||
| ### Supported | ||
|
|
||
| * Windows 7, 8, 8.1 | ||
| * RHEL 5.x, 6.x | ||
|
There was a problem hiding this comment. We currently don't support RHEL 5.x and do we have any customers that need support for it? We can probably get support for it fairly cheaply by leveraging the chef-client work (and I built the chefdk omnibus package initially on the old ci servers and had most of the other operating systems working when it was switched to new ci). By the same token FreeBSD, Debian and possibly even Solaris support will be fairly easy to leverage the client work that is already done. There was a problem hiding this comment. Expanding on this point, our goal is for ChefDK to be the thing that you install on your workstation to use Chef, period. I'm pretty sure we have a worthwhile chunk of user base using Arch/Gentoo/Fedora/Etc. for workstations. Do we want to add a note about how you get a new thing on this list (and how does that work)? Initially we want(ed) to keep the range of supported things pretty narrow so we can iterate quickly without spending a ton of time fixing weird platform issues, but eventually I think we need to support possibly a wider range of platforms than chef-client (but there won't be 100% overlap since some platforms are more common for workstation and some are used for servers almost exclusively). There was a problem hiding this comment. Yeah, 👍, we probably need Fedora support more than we need RHEL5 support. Probably more likely to encounter admins at RHEL shops that use Fedora on their desktop (to stay more up-to-date) than we'd encounter sites that still can't get their admin's workstations off of RHEL5. At the same time, though, I think there's another cost/benefit discussion that we've never had. We can probably get some low cost distros that leverage the chef-client support matrix that we've already got to support but which don't necessarily also have the highest benefit. I'd argue we ship those because it expands the matrix which should be viewed as being critical to our business. I think we've been resistant to do that, however, because it expands the support matrix and it may turn into a PITA. And we've been pretty terrible about being able to drop support for something once it has become painful (see ruby 1.8.7). The lack of ability to make agile decisions about dropping support seem to tie into the lack of agility in deciding to adopt distro support -- and larger distro support leads directly to more customers in this business, so that seems like a critical flaw in decision making that needs to get fixed. There was a problem hiding this comment. Yes, we need to have a broader set of DK supported platforms. On Wed, Jul 23, 2014 at 9:09 AM, Dan DeLeo notifications@github.com wrote:
|
||
| * Mac OS X 10.9 | ||
|
|
||
| ### Unsupported | ||
|
|
||
| * Windows Vista, XP, 2000, ME, 98, 95, 3.11 for Workgroups | ||
|
There was a problem hiding this comment. 😆 but should be removed. |
||
| * Mac OS X < 10.9, anything ppc | ||
|
There was a problem hiding this comment. Not sure this is correct, I think I've heard talk of support for 10.8. There was a problem hiding this comment. We have a similar lifecycle policy thing for ChefDK to what's in the appendix below, but is more aggressive about EOLing versions. I think it'd be a good idea to make that public, either via this RFC or a different one, and also revisit some of those decisions. The current policy for ChefDK on Mac is N, with N - 1 supported for a year (which we are not in compliance with). /cc @sersut There was a problem hiding this comment. @danielsdeleo Do you suggest that I write the N-1 policy for ChefDK in this document, even though we are not currently in compliance, and then we work to make it that way? |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should avoid religious references.