[chef] Re: Ideas for namespacing breaking attribute changes


Chronological Thread 
  • From: Matt Ray < >
  • To:
  • Cc:
  • Subject: [chef] Re: Ideas for namespacing breaking attribute changes
  • Date: Thu, 23 Jan 2014 15:16:46 -0600

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 :: 

mattray :: GitHub :: IRC :: Twitter


On Thu, Jan 23, 2014 at 3:10 PM, Bryan McLellan 
< >
 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.
>
> 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.

§