[chef] Re: Re: Ideas for namespacing breaking attribute changes

[Bryan McLellan < >]

On Thu, Jan 23, 2014 at 4: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.

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.

Bryan

[1] https://tickets.opscode.com/browse/OHAI-87