Accepted RFCs for October 15th


#1

I think maybe it would be good for the editor team to notify this mailing list when new RFCs are accepted and merged, for those that don’t have the bandwidth to keep up with the whole RFC process. Do people feel I should CC the Chef ML too?

This week five RFCs have been accepted, all planned for inclusion in Chef 12:

RFC 22: Arbitrary Cookbook Identifiers

This defines a new API to manage cookbooks with identifiers other the current three-integer-semver structure in use now.

RFC 23: Chef 12 Attributes Changes

This defines several new methods on Node to manipulate attributes. This will restore some functionality that was lost during the Chef 11 attributes rewrite, including safely deleting attributes and assigning over an existing hash.

RFC 24: Local Mode Default

This outlines plans to change chef-client and knife to use local-mode by default if no server URL is specified.

RFC 25: Multitenant Chef Client Support

This adds additional configuration options to better support multi tenant Chef Servers, such as Chef Server 12.

RFC 26: Remove HTTP Config Files

This deprecates a relatively unknown feature whereby chef-client can download its configuration directly from an HTTP server. Given how little this feature is believed to be used, an aggressive deprecation schedule will be used such that the feature will throw a warning in future Chef 11 versions and be entirely removed in Chef 12.

Thats all for this week. If you have thoughts on this bulletin, please let me know!

–Noah


#2

+1 for the idea of having reports such as this one on RFCs being accepted/merged. Just like btm’s Developer Office Hours reports, this is very useful/convenient to keep on top of things when one’s bandwidth is limited, as you say. Thanks! :slight_smile:

am

On 16 Oct 2014, at 09:18, Noah Kantrowitz noah@coderanger.net wrote:

I think maybe it would be good for the editor team to notify this mailing list when new RFCs are accepted and merged, for those that don’t have the bandwidth to keep up with the whole RFC process. Do people feel I should CC the Chef ML too?

This week five RFCs have been accepted, all planned for inclusion in Chef 12:

RFC 22: Arbitrary Cookbook Identifiers

https://github.com/opscode/chef-rfc/blob/master/rfc022-arbitrary-cookbook-identifiers.md

This defines a new API to manage cookbooks with identifiers other the current three-integer-semver structure in use now.

RFC 23: Chef 12 Attributes Changes

https://github.com/opscode/chef-rfc/blob/master/rfc023-chef-12-attributes-changes.md

This defines several new methods on Node to manipulate attributes. This will restore some functionality that was lost during the Chef 11 attributes rewrite, including safely deleting attributes and assigning over an existing hash.

RFC 24: Local Mode Default

https://github.com/opscode/chef-rfc/blob/master/rfc024-local-mode-default.md

This outlines plans to change chef-client and knife to use local-mode by default if no server URL is specified.

RFC 25: Multitenant Chef Client Support

https://github.com/opscode/chef-rfc/blob/master/rfc025-multitenant-chef-client-support.md

This adds additional configuration options to better support multi tenant Chef Servers, such as Chef Server 12.

RFC 26: Remove HTTP Config Files

https://github.com/opscode/chef-rfc/blob/master/rfc026-remove-http-config-files.md

This deprecates a relatively unknown feature whereby chef-client can download its configuration directly from an HTTP server. Given how little this feature is believed to be used, an aggressive deprecation schedule will be used such that the feature will throw a warning in future Chef 11 versions and be entirely removed in Chef 12.

Thats all for this week. If you have thoughts on this bulletin, please let me know!

–Noah


#3

Thanks Noah for the summaries!

RFC 26: Remove HTTP Config Files

This deprecates a relatively unknown feature whereby chef-client can
download its configuration directly from an HTTP server. Given how little
this feature is believed to be used, an aggressive deprecation schedule
will be used such that the feature will throw a warning in future Chef 11
versions and be entirely removed in Chef 12.

Sorry I missed the discussion on this particular RFC on chef-rfc repo, and
am unsure how to continue discussion on an already-accepted RFC - is that
detailed somewhere?

One point I’d like to ask about here is the “warning and deprecation” model

  • it appears that this is going to be removed completely in Chef 12, and a
    deprecation warning will be added to Chef 11.
    I’ve seen mention that there may not be any further Chef 11.x releases
    until Chef 12 is out, which actually makes the deprecation warning a little
    "too late" for anyone looking to upgrade and retain functionality.

Now, I don’t think this is The Most Important Feature that is likely to
cause massive breakage for users, but it does surface the need to describe
a clear deprecation methodology for anything that is going to be changed
significantly in Chef 12 and onwards.

RFC015 1 does a good job of defining a few of changes that are not
backwards compatible, but I don’t believe there’s any mention of adding
deprecation warnings in current Chef 11 for users of these features/code
paths.

From SemVer doc 2:

| How should I handle deprecating functionality?
| Deprecating existing functionality is a normal part of software
development and is often required to make forward progress. When you
deprecate part of your public API, you should do two things: (1) update
your documentation to let users know about the change, (2) issue a new
minor release with the deprecation in place. Before you completely remove
the functionality in a new major release there should be at least one minor
release that contains the deprecation so that users can smoothly transition
to the new API.

So it seems that the first part about updating documentation is happening
now, as well as will most likely be in the Chef 12 release notes, but the
second part about issuing a minor release of Chef 11 with deprecation
warnings (and any cookbooks that have deprecated code) should happen before
the Chef 12 release.

Best,
-M

On Thu, Oct 16, 2014 at 2:51 AM, Aimelyne Mochiron aimelynem@gmail.com
wrote:

+1 for the idea of having reports such as this one on RFCs being
accepted/merged. Just like btm’s Developer Office Hours reports, this is
very useful/convenient to keep on top of things when one’s bandwidth is
limited, as you say. Thanks! :slight_smile:

am

On 16 Oct 2014, at 09:18, Noah Kantrowitz noah@coderanger.net wrote:

I think maybe it would be good for the editor team to notify this
mailing list when new RFCs are accepted and merged, for those that don’t
have the bandwidth to keep up with the whole RFC process. Do people feel I
should CC the Chef ML too?

This week five RFCs have been accepted, all planned for inclusion in
Chef 12:

RFC 22: Arbitrary Cookbook Identifiers

https://github.com/opscode/chef-rfc/blob/master/rfc022-arbitrary-cookbook-identifiers.md

This defines a new API to manage cookbooks with identifiers other the
current three-integer-semver structure in use now.

RFC 23: Chef 12 Attributes Changes

https://github.com/opscode/chef-rfc/blob/master/rfc023-chef-12-attributes-changes.md

This defines several new methods on Node to manipulate attributes. This
will restore some functionality that was lost during the Chef 11 attributes
rewrite, including safely deleting attributes and assigning over an
existing hash.

RFC 24: Local Mode Default

https://github.com/opscode/chef-rfc/blob/master/rfc024-local-mode-default.md

This outlines plans to change chef-client and knife to use local-mode by
default if no server URL is specified.

RFC 25: Multitenant Chef Client Support

https://github.com/opscode/chef-rfc/blob/master/rfc025-multitenant-chef-client-support.md

This adds additional configuration options to better support multi
tenant Chef Servers, such as Chef Server 12.

RFC 26: Remove HTTP Config Files

https://github.com/opscode/chef-rfc/blob/master/rfc026-remove-http-config-files.md

This deprecates a relatively unknown feature whereby chef-client can
download its configuration directly from an HTTP server. Given how little
this feature is believed to be used, an aggressive deprecation schedule
will be used such that the feature will throw a warning in future Chef 11
versions and be entirely removed in Chef 12.

Thats all for this week. If you have thoughts on this bulletin, please
let me know!

–Noah


#4

On Oct 16, 2014, at 7:34 AM, Mike miketheman@gmail.com wrote:

Thanks Noah for the summaries!

RFC 26: Remove HTTP Config Files

https://github.com/opscode/chef-rfc/blob/master/rfc026-remove-http-config-files.md

This deprecates a relatively unknown feature whereby chef-client can download its configuration directly from an HTTP server. Given how little this feature is believed to be used, an aggressive deprecation schedule will be used such that the feature will throw a warning in future Chef 11 versions and be entirely removed in Chef 12.

Sorry I missed the discussion on this particular RFC on chef-rfc repo, and am unsure how to continue discussion on an already-accepted RFC - is that detailed somewhere?

One point I’d like to ask about here is the “warning and deprecation” model - it appears that this is going to be removed completely in Chef 12, and a deprecation warning will be added to Chef 11.
I’ve seen mention that there may not be any further Chef 11.x releases until Chef 12 is out, which actually makes the deprecation warning a little “too late” for anyone looking to upgrade and retain functionality.

Now, I don’t think this is The Most Important Feature that is likely to cause massive breakage for users, but it does surface the need to describe a clear deprecation methodology for anything that is going to be changed significantly in Chef 12 and onwards.

RFC015 [1] does a good job of defining a few of changes that are not backwards compatible, but I don’t believe there’s any mention of adding deprecation warnings in current Chef 11 for users of these features/code paths.

From SemVer doc [2]:

| How should I handle deprecating functionality?
| Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.

So it seems that the first part about updating documentation is happening now, as well as will most likely be in the Chef 12 release notes, but the second part about issuing a minor release of Chef 11 with deprecation warnings (and any cookbooks that have deprecated code) should happen before the Chef 12 release.

This is why I specifically called it out as an aggressive removal. Given how few people knew this feature existed, and how easy the workaround is, the conclusion was that going faster than SemVer recommends was okay in this instance. The resulting cleanup in the config code is substantial enough to warrant it in my opinion. No code has been merged yet though, so if you think this is a mistake I would start a new ML thread (just for visibility) :slight_smile:

–Noah


#5

On Thu Oct 16 11:09:24 2014, Noah Kantrowitz wrote:

On Oct 16, 2014, at 7:34 AM, Mike miketheman@gmail.com wrote:

Thanks Noah for the summaries!

RFC 26: Remove HTTP Config Files

https://github.com/opscode/chef-rfc/blob/master/rfc026-remove-http-config-files.md

This deprecates a relatively unknown feature whereby chef-client can download its configuration directly from an HTTP server. Given how little this feature is believed to be used, an aggressive deprecation schedule will be used such that the feature will throw a warning in future Chef 11 versions and be entirely removed in Chef 12.

Sorry I missed the discussion on this particular RFC on chef-rfc repo, and am unsure how to continue discussion on an already-accepted RFC - is that detailed somewhere?

One point I’d like to ask about here is the “warning and deprecation” model - it appears that this is going to be removed completely in Chef 12, and a deprecation warning will be added to Chef 11.
I’ve seen mention that there may not be any further Chef 11.x releases until Chef 12 is out, which actually makes the deprecation warning a little “too late” for anyone looking to upgrade and retain functionality.

Now, I don’t think this is The Most Important Feature that is likely to cause massive breakage for users, but it does surface the need to describe a clear deprecation methodology for anything that is going to be changed significantly in Chef 12 and onwards.

RFC015 [1] does a good job of defining a few of changes that are not backwards compatible, but I don’t believe there’s any mention of adding deprecation warnings in current Chef 11 for users of these features/code paths.

From SemVer doc [2]:

| How should I handle deprecating functionality?
| Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.

So it seems that the first part about updating documentation is happening now, as well as will most likely be in the Chef 12 release notes, but the second part about issuing a minor release of Chef 11 with deprecation warnings (and any cookbooks that have deprecated code) should happen before the Chef 12 release.

This is why I specifically called it out as an aggressive removal. Given how few people knew this feature existed, and how easy the workaround is, the conclusion was that going faster than SemVer recommends was okay in this instance. The resulting cleanup in the config code is substantial enough to warrant it in my opinion. No code has been merged yet though, so if you think this is a mistake I would start a new ML thread (just for visibility) :slight_smile:

–Noah

Since we’re going to be covering Chef 11 with security and critical
bugfix releases there will still be a support path for Chef 11 users
who hit deprecated features in Chef 12 and can’t upgrade right away.

We also have any deprecated features in Chef 12 for which there will be
no warning. We removed the dependency on rest-client for example
because no code in the chef-client codebase used rest-client any more
and it was causing problems. There is no deprecation warning and
likely will never be a deprecation warning because we’d need to somehow
monkeypatch rest-client to catch the use of it without an explicit
requires line outside of chef-client – that probably can in theory be
done (nearly anything can be done in ruby with an ugly enough
monkeypatch), but is incredibly fussy and would waste someone’s time
that could be better spent fixing bugs. So the deprecation warning is
going out in the CHANGELOG and RELEASE_NOTES and I’m again mentioning
it here. So, there are a few cookbooks that will not work out of the
box on Chef 12 without a patch and they will not have any deprecation
warnings (ever) in Chef 11.

SemVer mostly applies to WebAPIs or library calls where you can look at
your inputs and notify the user that they’re using the deprecated API.
In the case of chef-client we just instance_eval random ruby code and
expect you to be somewhat restrained in the size of the footgun that
you build. We can’t possibly follow SemVer to the letter in every case.


#6

Thanks Lamont!

I’m not specifically calling out rest-client removal as a point of
discussion, since it’s not part of the chef code “public API” - it wasn’t
being used in the codebase, any project that explicitly needs it should be
specifying that, agreed it can be removed with no point release, etc.

But for things which we do have current code in place that is part of
the public API of chef-client, such as the feature that was referenced (not
rest-client), we have the ability to add a deprecation notice (I believe
there’s even built-in methods in the Chef codebase, no?) so anyone looking
at logs can see them and act.

SemVer mostly applies to WebAPIs or library calls where you can look at
your inputs and notify the user that they’re using the deprecated API. In
the case of chef-client we just instance_eval random ruby code and expect
you to be somewhat restrained in the size of the footgun that you build.

I kind of object to this notion - SemVer is a specification in which
software - packaged, library or API call - can opt-in to adhere to or not,
and I was under some impression that Chef was attempting to follow Semantic
Versioning practices for software releases. If that’s not the case, please
let the rest of us know.

We can’t possibly follow SemVer to the letter in every case.

No, but we can definitely try. And if we can set a pattern in which we try
hard to adhere before finding a reason to not adhere, it’ll probably save
us heartache later on.

Best,
-M

On Thu, Oct 16, 2014 at 8:48 PM, Lamont Granquist lamont@opscode.com
wrote:

On Thu Oct 16 11:09:24 2014, Noah Kantrowitz wrote:

On Oct 16, 2014, at 7:34 AM, Mike miketheman@gmail.com wrote:

Thanks Noah for the summaries!

RFC 26: Remove HTTP Config Files

https://github.com/opscode/chef-rfc/blob/master/rfc026-
remove-http-config-files.md

This deprecates a relatively unknown feature whereby chef-client can
download its configuration directly from an HTTP server. Given how little
this feature is believed to be used, an aggressive deprecation schedule
will be used such that the feature will throw a warning in future Chef 11
versions and be entirely removed in Chef 12.

Sorry I missed the discussion on this particular RFC on chef-rfc repo,
and am unsure how to continue discussion on an already-accepted RFC - is
that detailed somewhere?

One point I’d like to ask about here is the “warning and deprecation"
model - it appears that this is going to be removed completely in Chef 12,
and a deprecation warning will be added to Chef 11.
I’ve seen mention that there may not be any further Chef 11.x releases
until Chef 12 is out, which actually makes the deprecation warning a little
"too late” for anyone looking to upgrade and retain functionality.

Now, I don’t think this is The Most Important Feature that is likely to
cause massive breakage for users, but it does surface the need to describe
a clear deprecation methodology for anything that is going to be changed
significantly in Chef 12 and onwards.

RFC015 [1] does a good job of defining a few of changes that are not
backwards compatible, but I don’t believe there’s any mention of adding
deprecation warnings in current Chef 11 for users of these features/code
paths.

From SemVer doc [2]:

| How should I handle deprecating functionality?
| Deprecating existing functionality is a normal part of software
development and is often required to make forward progress. When you
deprecate part of your public API, you should do two things: (1) update
your documentation to let users know about the change, (2) issue a new
minor release with the deprecation in place. Before you completely remove
the functionality in a new major release there should be at least one minor
release that contains the deprecation so that users can smoothly transition
to the new API.

So it seems that the first part about updating documentation is
happening now, as well as will most likely be in the Chef 12 release notes,
but the second part about issuing a minor release of Chef 11 with
deprecation warnings (and any cookbooks that have deprecated code) should
happen before the Chef 12 release.

This is why I specifically called it out as an aggressive removal. Given
how few people knew this feature existed, and how easy the workaround is,
the conclusion was that going faster than SemVer recommends was okay in
this instance. The resulting cleanup in the config code is substantial
enough to warrant it in my opinion. No code has been merged yet though, so
if you think this is a mistake I would start a new ML thread (just for
visibility) :slight_smile:

–Noah

Since we’re going to be covering Chef 11 with security and critical bugfix
releases there will still be a support path for Chef 11 users who hit
deprecated features in Chef 12 and can’t upgrade right away.

We also have any deprecated features in Chef 12 for which there will be no
warning. We removed the dependency on rest-client for example because no
code in the chef-client codebase used rest-client any more and it was
causing problems. There is no deprecation warning and likely will never be
a deprecation warning because we’d need to somehow monkeypatch rest-client
to catch the use of it without an explicit requires line outside of
chef-client – that probably can in theory be done (nearly anything can be
done in ruby with an ugly enough monkeypatch), but is incredibly fussy and
would waste someone’s time that could be better spent fixing bugs. So the
deprecation warning is going out in the CHANGELOG and RELEASE_NOTES and I’m
again mentioning it here. So, there are a few cookbooks that will not work
out of the box on Chef 12 without a patch and they will not have any
deprecation warnings (ever) in Chef 11.

SemVer mostly applies to WebAPIs or library calls where you can look at
your inputs and notify the user that they’re using the deprecated API. In
the case of chef-client we just instance_eval random ruby code and expect
you to be somewhat restrained in the size of the footgun that you build.
We can’t possibly follow SemVer to the letter in every case.