We’re talking in OHAI-542 [1] about changes to the cloud plugin that
would make it better but wouldn’t be backward compatible and one
option is to overload the attribute names with versions. We’ve had
issues with the network plugin in the past (OHAI-88 [2]) that lead to
similar questions, so it’s a bigger problem.
The top level namespace on nodes is pretty unlimited. But attributes
from ohai have “automatic” precedence (Ohai v7 [4] makes big
improvements here) so we want to be thoughtful.
Overloading attribute names with major version:
cloud
cloud2
cloud_2
cloud_v2
It seems like not overthinking it and adding only an integer to a
plugin is the easiest, e.g. the network2 plugin would provide
node[:network2][:blah_blah]. Since this should only happen on major
breaking rewrites, we don’t need to implement full semver versioning
in the attributes.
There’s an alternative idea floating around in my head that would
involve shipping both a cloud and cloud2 plugin, perhaps using
Chef::Config options to pick one until we replace the other on a major
release. But that still requires ripping off a bandaid eventually.
Also, I can’t get over feeling like Chef::Config using client.rb is
way off the beaten path, but it’s the only established method we have.
I really like the configuration option of shipping both and specifying
the one to use. Default to the old plugin, but start throwing
deprecation warnings, and then drop the old plugin in the Ohai shipped
with Chef 12? That gives people plenty of time to upgrade without
breaking anything, knowing that Chef 12 clearly will break this.
Thanks,
Matt Ray
Cloud Integrations Product Lead :: Chef
512.731.2218 :: matt@getchef.com
mattray :: GitHub :: IRC :: Twitter
On Thu, Jan 23, 2014 at 3:10 PM, Bryan McLellan btm@getchef.com wrote:
We're talking in OHAI-542 [1] about changes to the cloud plugin that
would make it better but wouldn't be backward compatible and one
option is to overload the attribute names with versions. We've had
issues with the network plugin in the past (OHAI-88 [2]) that lead to
similar questions, so it's a bigger problem.
The top level namespace on nodes is pretty unlimited. But attributes
from ohai have "automatic" precedence (Ohai v7 [4] makes big
improvements here) so we want to be thoughtful.
Overloading attribute names with major version:
cloud
cloud2
cloud_2
cloud_v2
It seems like not overthinking it and adding only an integer to a
plugin is the easiest, e.g. the network2 plugin would provide
node[:network2][:blah_blah]. Since this should only happen on major
breaking rewrites, we don't need to implement full semver versioning
in the attributes.
There's an alternative idea floating around in my head that would
involve shipping both a cloud and cloud2 plugin, perhaps using
Chef::Config options to pick one until we replace the other on a major
release. But that still requires ripping off a bandaid eventually.
Also, I can't get over feeling like Chef::Config using client.rb is
way off the beaten path, but it's the only established method we have.
On Thursday, January 23, 2014 at 1:16 PM, Matt Ray wrote:
I really like the configuration option of shipping both and specifying
the one to use. Default to the old plugin, but start throwing
deprecation warnings, and then drop the old plugin in the Ohai shipped
with Chef 12? That gives people plenty of time to upgrade without
breaking anything, knowing that Chef 12 clearly will break this.
The downside is that all cookbooks have to support both, or you have to upgrade everything in lockstep. You can’t have one cookbook that only supports v1 and another cookbook that only supports v2 in the same chef run.
On Thu, Jan 23, 2014 at 9:25 PM, Daniel DeLeo dan@kallistec.com wrote:
On Thursday, January 23, 2014 at 1:16 PM, Matt Ray wrote:
I really like the configuration option of shipping both and specifying
the one to use. Default to the old plugin, but start throwing
deprecation warnings, and then drop the old plugin in the Ohai shipped
with Chef 12? That gives people plenty of time to upgrade without
breaking anything, knowing that Chef 12 clearly will break this.
The downside is that all cookbooks have to support both, or you have to
upgrade everything in lockstep. You can’t have one cookbook that only
supports v1 and another cookbook that only supports v2 in the same chef run.
The backwards-incompatible version 3 update to the yum cookbook
demonstrates this problem. Restated, you can't start using the new one
until you first touch everything using the old one. This twists the
experience of using the new shiny into a yak-shaving exercise.
I'm in favour of two versions of the cloud attributes existing
side-by-side, the old one deprecated for a suitably long period before
being removed. I don't have a clear idea of what I think is a suitable
period, though - three to six months seems reasonable, a year onerously
long. If this approach was adopted, how could the old plugin be
deprecated? The plugin could log a deprecation warning, but this doesn't
help to identify anything using it. Logging when the deprecated attributes
are accessed might be nice in theory (albeit noisy), but I suspect is
impractical and/or an awful idea. Shipping Foodcritic rules to highlight
deprecated usage would be a help.
On Thu, Jan 23, 2014 at 4:16 PM, Matt Ray matt@getchef.com wrote:
I really like the configuration option of shipping both and specifying
the one to use. Default to the old plugin, but start throwing
deprecation warnings, and then drop the old plugin in the Ohai shipped
with Chef 12? That gives people plenty of time to upgrade without
breaking anything, knowing that Chef 12 clearly will break this.
Using the namespace would also give people plenty of time to upgrade,
and you could stop shipping the old plugin by default in some future
release. If users really wanted to keep using it, they could deploy
the plugin themselves and still not have any namespace conflict.
I don't like Chef::Config based solutions because you have to add
support for setting them to the BootstrapContext, because if you set
them in a Chef run then your initial bootstrap run isn't the same as
your second run. Looks like I started to talk about OHAI-87 [1] in my
original post but edited it out. There's an internal design that was
originally slated for Ohai v7 that is delayed to add
required_attributes/disabled_attributes configuration options as a
framework that would add a whitelist companion to the existing
blacklist functionality provided by the existing disabled_plugins
configuration (with a third run_mode option). This functionality would
also solve OHAI-87 by allowing you set some plugins, e.g. network and
fqdn, as required. It would make sense to solve the BootstrapContext
client.rb issue with that functionality.
I'm in favour of two versions of the cloud attributes existing
side-by-side, the old one deprecated for a suitably long period before
being removed.
+1.
As far as interval of time, since removing a plugin breaks backwards
compatibility, IMHO, this should only be done on a major revision bump. As
Bryan points out in the ticket [1], ohai is inherently linked to chef, so
we would need to wait for a major bump of chef as well (i.e. v12).
The plugin could log a deprecation warning, but this doesn't help to
identify anything using it... Shipping Foodcritic rules to highlight
deprecated usage would be a help.
+1 to the food critic rule idea.
Proposal
Adopt a versioning syntax in the plugin namespace of "<plugin_name>[_vN]".
Where, "N" is the version of the plugin. A version of "1" is implied if
the "_vN" is omitted.
For example:
node["cloud"] is v1 of the cloud plugin,
node["cloud_v2"] is v2 of the cloud plugin,
and so forth...
Given this syntax is should be fairly straightforward to write a foodcritic
rule to report about the usage of deprecated namespaces.