Cookbook metadata - add chef version compatibility info


#1

Hi all,

I would like to propose an addition to cookbook metadata - a chef version
compatibility deceleration which declares which Chef version a cookbook can
be used with.
This will aid users to understand if a cookbook might break on chef
upgrades - i think the chef 11 migration has demonstrated the need of such
metadata.

some like:
compatible “>= 11.0.0”

what say you?


#2

+1 for more descriptive metadata in cookbooks.

Maybe “chef_version”, or hell, a subset of “supports” (which is unused…)

-M

On Tue, Apr 16, 2013 at 11:02 AM, Avishai Ish-Shalom
avishai@fewbytes.com wrote:

Hi all,

I would like to propose an addition to cookbook metadata - a chef version
compatibility deceleration which declares which Chef version a cookbook can
be used with.
This will aid users to understand if a cookbook might break on chef upgrades

  • i think the chef 11 migration has demonstrated the need of such metadata.

some like:
compatible “>= 11.0.0”

what say you?


#3

I think everyone wants something like this, the two questions are what exactly it should look like, and how we get there from here.

First of all, we should think about whether chef version is the correct property to look at. For example, we could imagine adding new syntax (e.g., platform family) to two release tracks of chef, such that, say, 10.30+ or 11.6+ would work, but 11.0-11.4 would not. It may also be the case that someone who can’t or won’t upgrade wants to backport the required feature via a cookbook. If these use cases are important, we might consider a design where chef exposes a list of capabilities it provides and cookbooks depend on specific capabilities rather than chef versions.

As for implementation and execution, we need to take a look at how chef server handles unknown keys in metadata (and other potential compat issues) to see what the constraints on the implementation might be.


Daniel DeLeo

On Tuesday, April 16, 2013 at 9:35 AM, Mike wrote:

+1 for more descriptive metadata in cookbooks.

Maybe “chef_version”, or hell, a subset of “supports” (which is unused…)

-M

On Tue, Apr 16, 2013 at 11:02 AM, Avishai Ish-Shalom
avishai@fewbytes.com wrote:

Hi all,

I would like to propose an addition to cookbook metadata - a chef version
compatibility deceleration which declares which Chef version a cookbook can
be used with.
This will aid users to understand if a cookbook might break on chef upgrades

  • i think the chef 11 migration has demonstrated the need of such metadata.

some like:
compatible “>= 11.0.0”

what say you?


#4

hmm… you raise good points. we could use multiple compatible clauses
which solves the problem of multiple release tracks, but i like your
feature oriented suggestion. so this would look something like:

provides_features :feature_name, :another_feature_name
depends_features :whyrun, :lwrp_inline_resources

the downside is that there will have to be a relatively big ramp up to get
features named, defined and declared.

as for chef server handling of metadata, i’ll test when i have some time.

On Tue, Apr 16, 2013 at 7:53 PM, Daniel DeLeo dan@kallistec.com wrote:

I think everyone wants something like this, the two questions are what
exactly it should look like, and how we get there from here.

First of all, we should think about whether chef version is the correct
property to look at. For example, we could imagine adding new syntax (e.g.,
platform family) to two release tracks of chef, such that, say, 10.30+ or
11.6+ would work, but 11.0-11.4 would not. It may also be the case that
someone who can’t or won’t upgrade wants to backport the required feature
via a cookbook. If these use cases are important, we might consider a
design where chef exposes a list of capabilities it provides and cookbooks
depend on specific capabilities rather than chef versions.

As for implementation and execution, we need to take a look at how chef
server handles unknown keys in metadata (and other potential compat issues)
to see what the constraints on the implementation might be.


Daniel DeLeo

On Tuesday, April 16, 2013 at 9:35 AM, Mike wrote:

+1 for more descriptive metadata in cookbooks.

Maybe “chef_version”, or hell, a subset of “supports” (which is unused…)

-M

On Tue, Apr 16, 2013 at 11:02 AM, Avishai Ish-Shalom
avishai@fewbytes.com wrote:

Hi all,

I would like to propose an addition to cookbook metadata - a chef version
compatibility deceleration which declares which Chef version a cookbook can
be used with.
This will aid users to understand if a cookbook might break on chef
upgrades

  • i think the chef 11 migration has demonstrated the need of such metadata.

some like:
compatible “>= 11.0.0”

what say you?