[chef] Ideas for namespacing breaking attribute changes


Chronological Thread 
  • From: Bryan McLellan < >
  • To:
  • Subject: [chef] Ideas for namespacing breaking attribute changes
  • Date: Thu, 23 Jan 2014 16:10:45 -0500

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.

Any other ideas?

-- 
Bryan McLellan | chef | software engineer
(c) 206.607.7108 | (t) @btmspox | (www) http://getchef.com

[1] https://tickets.opscode.com/browse/OHAI-542
[2] https://tickets.opscode.com/browse/OHAI-88
[3] https://tickets.opscode.com/browse/OHAI-87
[4] http://docs.opscode.com/release/ohai-7/release_notes.html



Archive powered by MHonArc 2.6.16.

§