hmm… you raise good points. we could use multiple
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 firstname.lastname@example.org 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.
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…)
On Tue, Apr 16, 2013 at 11:02 AM, Avishai Ish-Shalom
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
- i think the chef 11 migration has demonstrated the need of such metadata.
compatible “>= 11.0.0”
what say you?