There are several answers with metal, including openstack and vsphere, but the closest to what you have is Hanlon, with the chef-provisioning-hanlon driver. It is more beta than some of the rest of provisioning, but improving rapidly.
There still seems be a huge gap in the bare metal area. Something like what puppets razor module has done . Some of us still have data centers and have to deploy physical hosts :) . Using chef end to end to deploy an ESXi cluster and configure it would be amazing .I basically have a small puppet vm to run razor because it works so well with our current Cisco UCS deployment . Would love to get rid of it
Sent from my iPhoneI'll explain the thinking and then the plan :) Two of Chef's big goals are to let you:1. Describe your whole infrastructure in recipes.2. Reuse the same recipes across the dev/test/deploy workflow wherever possible.This means that we want to have resources for everything; but that they don't all have to be abstractions.Chef Provisioning implements the secondary goal with abstractions like machine; but as Julian says, not everything can (or should) be abstracted. The plan is to provide abstractions where they are meaningful, and to provide cloud-, container- or vm-specific resources to manage things that don't fit that model.On Mon, Nov 17, 2014 at 6:55 PM, Julian C. Dunn < " target="_blank"> > wrote:On Mon, Nov 17, 2014 at 6:12 PM, Torben Knerr < " target="_blank"> > wrote:
> Is the intention to provide some common abstractions (e.g for cloud
> queues, object storage, load balancers, etc) like Vagrant does for
> virtual machines too? Or is the aim to simply provide a higher level
> configuration DSL in favor of the specific commandline tools?
I'm not sure. John Keiser would be the best person to answer.
However... I have talked to some folks about this and they've warned
us off the idea, because there is actually less commonality than you
might think amongst the cloud providers.
Since I don't have broad operational experience with anything beyond
AWS I thought I'd merely relate that. If anyone can weigh in, we'd
certainly welcome the feedback.
- Julian
--
[ Julian C. Dunn < " target="_blank"> > * Sorry, I'm ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]
Archive powered by MHonArc 2.6.16.