thanks, indeed Vagrant is focused on virtual machines only, good to
know where Chef Provisioning is heading to.
While at first I couldn’t find the additional resources in
opscode/chef-provisioning itself, I found them in
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?
On Mon, Nov 17, 2014 at 10:33 PM, Julian C. Dunn email@example.com wrote:
On Mon, Nov 17, 2014 at 12:21 PM, Torben Knerr firstname.lastname@example.org wrote:
with the recent blog post about “Chef Provisioning” I believe this
means that chef-metal went live:
Yes, just to be clear, “Chef Provisioning” is what was previously
known as “Chef Metal”. We renamed it because there was confusion in
that it isn’t just to automate bare metal.
Something I was always wondering about: there seems to be a huge
overlap between Chef Metal and Vagrant – is this by intent? Which
gaps does chef-metal try to fill and what can I do with chef-metal
that I can’t do well with vagrant?
Chef Provisioning is intended to be a platform that’ll allow you to
automate all aspects of your stack. For example, if you’re in AWS,
various AWS objects like SNS topics, SQS queues, IAM users, ELBs, etc.
can be managed. Vagrant doesn’t have those capabilities; it deals only
There are also other features like parallelization (via the
machine_batch resource) that Vagrant won’t have.
Those are some of the things I can think of, off the top of my head.
[ Julian C. Dunn email@example.com * 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 ]