We’ve been discussing how to build an upgrade mechanism into Chef. The proposal is currently an RFC - https://github.com/chef/chef-rfc/pull/171 -and we’d like to get as much feedback from you - our users - as possible so we can make the best system possible.
We’d like to understand:
How you would like to control an upgrade mechanism? Some possible options would be:
- an attribute, that would be set on a node or environment
- something in your
- something else
When you run chef-client, when should an upgrade happen?
- Right at the start, before the compile phase happens
- Right at the end, just before we reboot if we need to
- When you include the
chef_upgrade resource - this is how the
omnibus_updater cookbook works now
Any other thoughts you have about upgrading Chef?
I like the idea of making it happen right at the start – would save me from writing more backwards compatible code. It wouldn’t be that big of a deal though for it to happen at the end of a run.
I’d be fine with just about any control options mentioned.
Yes I think I’d like it to happen at the beginning for similar reasons.
Would this support downgrading too?
My $N cents,
I would like to see it happen by default at the start of the run. For simplicity I would use a node attribute with a special name (
node['__chef_upgrade_version__'] or something similarly non-collide-y) which gets checked after loading envs/roles but before cookbook download. If the attribute is unset, nothing happens and we carry on. If it is set and
Chef::VERSION matches the value, continue. Otherwise we are starting and upgrade (or downgrade, it doesn’t care). This kicks off a mini-converge using a
chef_upgrade resource to handle the download et al.
This provides minimal footgun while allowing more flexibility by leaving the attribute unset and using the resource manually at either compile or converge time.
This is definitely a welcome feature. My team ended up spending a whole bunch of time trying to figure out the best way to upgrade the Chef Client package for the matrix of platforms we need to support. It would be great to have an official mechanism to do this (or, at the very least, a documented way for best practices).
We ended up creating the chef-updater cookbook which is very similar to how the Omnibus Updater cookbook operates. Our main difference is that we were using an internal HTTP service to host the artifacts instead of Omnitruck API.
We are looking at how to do this so it would be great to have it built into chef. Two things I would like to see are the ability to use an internal repository and the ability to specify the client version.