Platform support policy proposal by juliandunn · Pull Request #21 · chef-boneyard/chef-rfc

juliandunn · 2014-07-17T05:05:42Z

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.

sethvargo · 2014-07-17T15:34:43Z

platform-support-policy.md

I would seriously like to have a conversation about our continued support of 32-bit builds, especially for newer OS.

@sethvargo probably not something we need to "officially" support, but there's definitely 32-bit embedded devices that people run Chef on.

@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.

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.

schisamo · 2014-07-17T18:39:42Z

platform-support-policy.md

Ubuntu 10.04

Ubuntu 11.04

Ubuntu 12.04

Ubuntu 14.04 (needs to be added to matrix)

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.

Agreed, there is no reason we should be building for vendor EOL'd operating systems IMO.

danielsdeleo · 2014-07-18T01:57:26Z

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?

juliandunn · 2014-07-18T05:53:30Z

@danielsdeleo Here's my view, and we can discuss it before I add it to the doc.

We don't kill a distro version before the vendor does
For Windows, we support until the end of Extended Support (example: Windows 2003R2 to July 14, 2015)
For RHEL, to the end of Production 3 Phase (March 31, 2017 for RHEL 5, November 30, 2020 for RHEL 6)
For Ubuntu, there is no phased support, so whenever Canonical ends support, we do too

Comments?

danielsdeleo · 2014-07-18T16:20:36Z

@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:

For Solaris, do we end support with "premier support" or "extended support"? (See: http://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf page 34).
Apple never officially announces EOL, you basically have to follow a bunch of Apple blogs to find out when they stop shipping security updates for Safari on that version to determine EOL. So I think we ought to come up with a plan like N - 1 or N - 2 for OS X.
With RHEL, we've had some issues with software built on, for example, 5.8 not working on 5.2. I think we need specifics about how we handle that.

juliandunn · 2014-07-18T16:52:02Z

For Solaris I'm going to say end of "premier" is fine, since that's a minimum of ten years. That commits us to support Solaris 9 only until October of this year, by the way.
For OS X I'd suggest N - 2, which means we'd do 10.7+ at this point.
With EL, perhaps we should say that we'll support the lowest of whatever we build on, to be safe? e.g. if we're building on 5.8, then we say 5.8+? This probably has some implications for releng since they won't be able to simply run the latest 5.x / 6.x / 7.x on the slaves. /cc @schisamo

danielsdeleo · 2014-07-18T17:02:45Z

@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.

@danielsdeleo

lifecycle support terminology per @danielsdeleo

yvovandoorn · 2014-07-18T23:14:34Z

@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.

coderanger · 2014-07-18T23:17:04Z

platform-support-policy.md

We should avoid religious references.

juliandunn · 2014-07-19T04:36:44Z

@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.

coderanger · 2014-07-19T21:40:25Z

👍

stevendanna · 2014-07-31T12:28:54Z

platform-support-policy.md

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.

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.

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

Not to be pedantic, but you probably want to use "eg." rather than "i.e."

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.

Ah, sorry, I misunderstood. I thought there were other examples still to be named.

I'd still like to see i.e. added here as a minimum explanation that these three resources are, in fact, requirements.

Tech356 · 2014-09-04T17:19:07Z

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.

sersut · 2014-09-04T19:56:50Z

@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.

danielsdeleo · 2014-09-04T20:28:55Z

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.

juliandunn · 2014-09-04T20:55:42Z

@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.

lamont-granquist · 2014-09-04T21:40:55Z

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.

juliandunn · 2014-09-04T21:53:24Z

@lamont-granquist decoupling testing from building is not what @sersut and @schisamo want to do.

lamont-granquist · 2014-09-05T00:08:12Z

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.

benlangfeld · 2014-09-05T17:21:22Z

platform-support-policy.md

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)

@sersut - want to comment?

For what it is worth, I am interested in seeing this happen as well.

Tech356 · 2014-09-05T18:19:21Z

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.

juliandunn · 2014-09-05T19:38:56Z

@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?

jordane · 2014-09-05T21:59:16Z

@Tech356 Windows XP and Vista are specifically listed as not supported while Windows 7, 8, and 8.1 are listed under Chef-DK

Tech356 · 2014-09-05T22:01:19Z

@jordane Yes, for the Chef-DK. I am asking about the Chef-Client.

jordane · 2014-09-05T22:02:19Z

@Tech356 Chef-DK includes Chef-Client, which implies Chef-Client support..

Tech356 · 2014-09-05T22:06:35Z

@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.

lamont-granquist · 2014-09-05T23:07:52Z

I agree with @jordane and @Tech356, spell this out very explicitly. I particular, I'd like to see @Tech356 statement that "Chef-DK includes Chef-Client, which implies Chef-Client support" addressed.

adamhjk · 2014-09-09T21:42:15Z

Lets make it explicit in the document. Chef-Client is a superset of
Chef-DK. So no platform considered supported by the DK is not supported by
the Chef client.

Adam

On Fri, Sep 5, 2014 at 4:07 PM, lamont-granquist notifications@github.com
wrote:

I agree with @jordane https://github.com/jordane and @Tech356
https://github.com/Tech356, spell this out very explicitly. I
particular, I'd like to see @Tech356 https://github.com/Tech356
statement that "Chef-DK includes Chef-Client, which implies Chef-Client
support" addressed.

—
Reply to this email directly or view it on GitHub
#21 (comment).

…mployees Mark Windows 7, 8 and 8.1 as explicitly supported (since they are shipped inside the ChefDK)

juliandunn · 2014-09-18T15:04:24Z

I have addressed the major outstanding issues in preparation for merge.

Removed language tying us to a specific, prescriptive bar for post-build verification of Tier 1 platforms
Called out that desktop platforms are supported by Chef Client by virtue of ChefDK

jordane · 2014-09-18T16:54:05Z

platform-support-policy.md

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?

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.)

Okay, cool.

adamhjk · 2014-10-02T17:44:08Z

I am the decider, and I Approve This RFC. 👍

Added initial draft of platform support policy

aac5282

sethvargo reviewed Jul 17, 2014
View reviewed changes

Update ChefDK Mac support

fe7b46a

schisamo reviewed Jul 17, 2014
View reviewed changes

Added missing RHEL row

f03b11d

juliandunn changed the title ~~Added initial draft of platform support policy~~ Platform support policy proposal Jul 18, 2014

Julian C. Dunn added 2 commits July 18, 2014 17:51

Update Gentoo, Arch, OpenSUSE; add clarifications for upstream vendor

cd6eda6

lifecycle support terminology per @danielsdeleo

Damn I don't know how to <table>

9421dcf

coderanger reviewed Jul 18, 2014
View reviewed changes

platform-support-policy.md Outdated

Copy link
Copy Markdown

Contributor

coderanger Jul 18, 2014

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.

Accept most modifications from @coderanger

fd72050

stevendanna reviewed Jul 31, 2014
View reviewed changes

danielsdeleo mentioned this pull request Aug 6, 2014

Error installing chef on CoreOS chef/chef#1735

Closed

benlangfeld reviewed Sep 5, 2014
View reviewed changes

Julian C. Dunn added 2 commits September 18, 2014 09:59

Clarify 'post-build-verification' language per discussion with Chef e…

293d098

…mployees Mark Windows 7, 8 and 8.1 as explicitly supported (since they are shipped inside the ChefDK)

Call out the superset relationship between ChefDK and Chef Client.

914a9e4

jordane reviewed Sep 18, 2014
View reviewed changes

juliandunn mentioned this pull request Sep 24, 2014

chef-full.erb bootstrap template only supports bash chef/chef#2037

Closed

schisamo mentioned this pull request Sep 26, 2014

SmartOS can't install SVR4-style Solaris packages chef/omnibus#321

Closed

Fix typo thanks @scotthain

ebdb9f3

jonlives merged commit ebdb9f3 into chef-boneyard:master Oct 2, 2014

juliandunn deleted the platform-support-policy branch October 2, 2014 17:50

Conversation

juliandunn commented Jul 17, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danielsdeleo commented Jul 18, 2014

Uh oh!

juliandunn commented Jul 18, 2014

Uh oh!

danielsdeleo commented Jul 18, 2014

Uh oh!

juliandunn commented Jul 18, 2014

Uh oh!

danielsdeleo commented Jul 18, 2014

Uh oh!

yvovandoorn commented Jul 18, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juliandunn commented Jul 19, 2014

Uh oh!

coderanger commented Jul 19, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tech356 commented Sep 4, 2014

Uh oh!

sersut commented Sep 4, 2014

Uh oh!

danielsdeleo commented Sep 4, 2014

Uh oh!

juliandunn commented Sep 4, 2014

Uh oh!

lamont-granquist commented Sep 4, 2014

Uh oh!

juliandunn commented Sep 4, 2014

Uh oh!

lamont-granquist commented Sep 5, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tech356 commented Sep 5, 2014

Uh oh!

juliandunn commented Sep 5, 2014

Uh oh!

jordane commented Sep 5, 2014

Uh oh!

Tech356 commented Sep 5, 2014

Uh oh!

jordane commented Sep 5, 2014

Uh oh!

Tech356 commented Sep 5, 2014