Platform support policy proposal #21
Conversation
| 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 | ||
| Windows | 2003R2, 2008, 2008R2, 2012, 2012R2 | x86 and x86_64 | msi | Windows 2008R2 | ||
| 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.
|
|
||
| ### Supported | ||
|
|
||
| * Ubuntu (which versions?) |
There was a problem hiding this comment.
- Ubuntu 10.04
- Ubuntu 11.04
- Ubuntu 12.04
- Ubuntu 14.04 (needs to be added to matrix)
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.
|
What about the lifecycle of distribution support? Would we ever kill a distro version before the vendor does? What about extended EOL stuff that Red Hat does? Do we kill a version once you have to pay for security updates, or only when it's 100% unsupported? |
|
@danielsdeleo Here's my view, and we can discuss it before I add it to the doc.
Comments? |
|
@juliandunn supporting RHEL 5 until 2017 doesn't appeal to me, but as Hyman Roth says, "this is the business we've chosen." Or in other words, 👍 on the items listed. Others:
|
|
|
@juliandunn Actually, premier support seems to be over for Solaris 9, while extended support ends this October. I'd be thrilled to kill off Solaris 9 since it's stuck on older hardware which is absurdly slow. |
juliandunn
changed the title
lifecycle support terminology per @danielsdeleo
|
@juliandunn My only concern is the mismatch between "Extended" for Microsoft and only "End of Production" for Red Hat (when they offer an Extended as well). It seems that Microsoft has a similar "End of Production" end date, but name it "Mainstream support". I think the majority can agree that changing Red Hat to "Extended" would be painful. Yes this could potentially mean that Windows 2008 R2 is expiring early Jan 2015, but I suspect Microsoft will bump up Mainstream support for R2 and retire regular (R1?) 2008 support that day. |
| 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 |
There was a problem hiding this comment.
We should avoid religious references.
|
@yvovandoorn That's why I think it's important to enumerate here what the intended outcomes are, even if vendors choose completely different terminology to refer to things ("premium", "extended", "end of production", etc.) As you know we need to strike a balance between engineering effort to maintain supportability against disappointing customers who are running older operating systems and will continue to do so. Hence I would not wish to end support for Windows 2008R2 as soon as January 2015. |
|
👍 |
| A Chef Client supported platform means: | ||
|
|
||
| * Omnitruck won't fail when confronted with the platform and version | ||
| * The most important core resources (package, service, template) work out of the box |
There was a problem hiding this comment.
Is the parenthetical list supposed to be everything we consider "core resources" or simply examples? If it is an example, is it worth it to enumerate the full list? I fear the endless bikeshed that could come from such a list. However, it is hard to imagine calling a platform "supported" without user, group, file, and directory also working.
There was a problem hiding this comment.
No, that is the intended actual list. It's what @adamhjk refers to as the "holy trinity of resources" but there were some complaints about that language, so I reworded it.
There was a problem hiding this comment.
could you add i.e. to that list? so those who are looking closely can interpret that as a complete list?
* The most important core resources (i.e. package, service, template) work out of the box
There was a problem hiding this comment.
Not to be pedantic, but you probably want to use "eg." rather than "i.e."
There was a problem hiding this comment.
I.e. is correct in this case, as package, service and template are actually the only 'most important core resources' in existence, and not merely examples of them.
There was a problem hiding this comment.
Ah, sorry, I misunderstood. I thought there were other examples still to be named.
There was a problem hiding this comment.
I'd still like to see i.e. added here as a minimum explanation that these three resources are, in fact, requirements.
|
I understand my use case is unique and Chef Software can't make a decision to support an OS simply for one use case, but I would like to see Window 7 added to the Tier 1 support. I have quite a few nodes that are Windows 7. |
|
@juliandunn can you remind the reason behind not adding Windows Client versions to the Tier 1 list? We obviously have other "Client" versions like Mac 10.X in Tier 1 support list. |
|
IMO, it's a cost/benefit thing. For all tier 1 platforms, we have test infrastructure, which means the probability of random test failure increases, management burden is higher, etc.; we test client on virtually identical systems, just the server OS flavor. So either we relax the language about testing, move Windows workstation flavors to tier 2, or add testers for them. |
|
@sersut OS X is in there because people regularly run it as a server. You don't run Windows 7 as a server platform though. |
|
That is splitting hairs. People have images that they need to manage and desktop OSX and Win 7 images are also critical to the Enterprises that they're in. I still say we need to be able to say to customers that we support a platform as Tier 1 and decouple that from if we actually have a tester or not. Because I'm willing to bet money we can support Win 7 as a Tier 1 image very cheaply even though we don't test on it. |
|
@lamont-granquist decoupling testing from building is not what @sersut and @schisamo want to do. |
|
Its not decoupling testing from building, its decoupling support level from testing. And there are simple results which are going to be that either we're going to needlessly test in order to support, or needlessly fail to support because we don't have the resources to test. |
| * Fedora (current non-EOL releases) | ||
| * RHEL 6.x | ||
| * Mac OS X 10.8, 10.9 | ||
| * Ubuntu 12.04, 13.10, 14.04 |
There was a problem hiding this comment.
Might it be possible to additionally support Debian, since there should be minimal difference in packaging from Ubuntu? See also chef-boneyard/chef-dk#51 (comment)
There was a problem hiding this comment.
@sersut - want to comment?
There was a problem hiding this comment.
For what it is worth, I am interested in seeing this happen as well.
|
Is it Chef's policy to only support servers? Before this RFC is merged, I would like to see Window xp/vista/7/8 added to either the "Tier 1 Support", "Tier 2 Support", or "Not Supported" sections to know where Chef Software stands on using the Chef Client on these platforms. |
|
@lamont-granquist that is what I meant. @sersut and @schisamo don't want to do that. I'm just a scribe trying to keep up with the wishes of the group, so between the three of you if you can tell me whether it should be coupled or decoupled, I'll write it appropriately. And at that point, one important question will become, what is the distinguishing characteristic between Tier 1 and Tier 2? |
|
@Tech356 Windows XP and Vista are specifically listed as not supported while Windows 7, 8, and 8.1 are listed under Chef-DK |
|
@jordane Yes, for the Chef-DK. I am asking about the Chef-Client. |
|
@Tech356 Chef-DK includes Chef-Client, which implies Chef-Client support.. |
|
@jordane According to the conversion above, I doesn't seem like it is implied. If it is, then I would like it to be said so explicitly. |
|
Lets make it explicit in the document. Chef-Client is a superset of Adam On Fri, Sep 5, 2014 at 4:07 PM, lamont-granquist notifications@github.com
|
…mployees Mark Windows 7, 8 and 8.1 as explicitly supported (since they are shipped inside the ChefDK)
|
I have addressed the major outstanding issues in preparation for merge.
|
| * Mac OS X 10.8, 10.9 | ||
| * Ubuntu 12.04, 14.04 | ||
|
|
||
| ChefDK bundles Chef Client. Therefore, Chef Client is supported, by extension, on the foregoing client platforms, if not already mentioned explicitly in the Chef Client support matrix. |
There was a problem hiding this comment.
Since we're already being explicit, it'd be nice to mention which tier they count as (I'm assuming Tier 1?). Or would ChefDK count as its own tier in the Chef Client matrix?
There was a problem hiding this comment.
I actually put the desktop Windows platforms in the matrix, so it covers us off - this was just extra insurance in case I missed anything. (We would generally consider them Tier 1.)
|
I am the decider, and I Approve This RFC. 👍 |
There is a fair amount of confusion about the specific operating system platforms, platform versions, etc. that Chef Software, Inc. supports for its products. This RFC will clarify this by calling out the individual operating systems and their releases as explicitly supported or not.