[chef] Re: Re: Re: Re: Chef Metal vs. Vagrant

[John Keiser < >]

I'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 < "> > 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 < "> >          * 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       ]