[chef] Re: Re: Re: chef-metal vs chef-container?

[Martin Cleaver < >]

I found it baffling why chef-metal (which is not at all bare metal but rather an orchestration tool) wasn't named something more intention-revealing.

Chef-metal may have been a better name for chef-hanlon.

And chef-metal could have been called something like chef-orchestration.

Not sure what the names would be better as, and I appreciate tools evolve, but I do feel ambiguity causes extra tools to spring up when attention could be better focused if names helped with the wayfinding.

Cheers, M.

Sent from my iPhone

On Aug 29, 2014, at 2:58 PM, Bryan McLellan < "> > wrote:

On Fri, Aug 29, 2014 at 2:50 PM, Ranjib Dey < " target="_blank"> > wrote:

Chef-metal does not support bare metal provisioning yet :-) (not sure an iPXE driver may be on its way ). While chef-container does not support LXC, openvz, solaris, WPAR, systemd-nspawn, lmctfy or any other containers, and i think by design it will only support docker. Also, note, philosophically docker ecosystem does not like changing container images post creation. Chef based containers does not violate this, but makes it easy to do so.

Chef-metal recently added image resource which can be used as a software abstraction across ami, lxc images etc.

There is some chef-metal bare metal work going on, like a Hanlon driver. 

https://github.com/opscode/chef-metal-hanlon

https://github.com/csc/Hanlon

Bryan