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


Chronological Thread 
  • From: Torben Knerr < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Re: Re: Chef Metal vs. Vagrant
  • Date: Tue, 18 Nov 2014 22:43:24 +0100

Thanks everybody for the responses!

@Sören, Martin - thanks for pointing me to terraform again. I looked
at it once in the early stages but then basically forgot about it...

@JulianDunn, JohnKeiser - makes sense, much clearer now. +1 for
providing abstractions only where meaningful rather than being leaky
;-)


On Tue, Nov 18, 2014 at 7:20 PM, John Keiser 
< >
 wrote:
> 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 
> < >
>  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       ]
>
>



Archive powered by MHonArc 2.6.16.

§