[chef] Re: Re: Infrastructure Deployment Specification


Chronological Thread 
  • From: Miquel Torres < >
  • To:
  • Subject: [chef] Re: Re: Infrastructure Deployment Specification
  • Date: Thu, 19 May 2011 12:57:45 +0200
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=X7r++5w9+gLHqhjPeoBYO+10mrLky/b/+RLUB6u+5ylzux7vPWu2Qare0W7cYIfV4I LaMsD+6foYBeMC5jyVtvUYDCOKFiNNV1C8i6+oZ9IzRLSQOHlBgwReLMGrI5v+LqgUYd hT0z0eOTWZHK0YkPoYjyJaJvBSuLw/eFEsofk=

Nice to see that we all see the need to do this.

@Kevin: there are many, many features a deployment spec can have. The
problem of having too many is that it will then be nigh on impossible
to agree on a common set. Maybe we can define a "core" spec, easy to
implement, that more or less has the basic features the current draft
has, and then have optional extensions for things like scheduling,
DNS, cross-referencing of nodes and so on.

@John: Tha's the idea, that the other tools use the same spec. Having
a common, standardized spec that all tools implement brings many
advantages to a community. It should be also easy to write a knife
plug-in that implements the spec.

@Hedge: yeah, Vagrant could also get on the boat. Then you could use a
deployment file in Vagrant for developing and testing with several
VMs, and then just change Provider to a proper cloud and deploy in
production.

Cheers,
Miquel


2011/5/18 Hedge Hog 
< >:
> On Wed, May 18, 2011 at 12:43 AM, Miquel Torres 
> < >
>  wrote:
>> Hi all.
>>
>> The launch of CloudFormation, Spiceweasel development Judd's Swift
>> work and that of Eric Heydrick (not yet seen in the open) are all
>> testament to an accelerating interest in improving the integration of
>> server provisioning and configuration management. Which is no wonder,
>
> You also might like to reach out and bring this to the attention of
> the Vagrant mail list/community.
>
> Best wishes
>
>> because the possibility of automatically launching whole server
>> clusters that are then configured by Chef, all by issuing a single
>> command is not only exciting but useful.
>>
>> The approach so far, however, has been at the tool level, with each
>> project going its own way.
>>
>> I think that server provisioning should also be written in code. What
>> kind of servers an application needs is a valuable knowledge. How much
>> memory or computing power does this kind of server in your stack need?
>> "Ask the operations guy" is the current answer. That is wrong. Chef is
>> trying to take us to a better world, where server configuration is a
>> known quantity you store in code. Why treat server provisioning
>> differently?
>>
>> That is why Grig Gheorghiu and I have started an Infrastructure
>> Deployment Specification initiative. LittleChef is going to implement
>> it using libcloud, but the hope is that all the projects centred
>> around Chef and provisioning agree on a common specification, similar
>> in syntax to Chef roles and recipes, and which you can use across
>> tools and clouds.
>>
>> You can find a first draft (which is purposely simple) here:
>>    http://tobami.github.com/Infrastructure-Deployment-Spec/
>>
>> Please join us in defining a useful specification that everyone can
>> use. We are of course specially interested in the input from projects
>> like Spiceweasel, and people like Judd Maltin and Eric Heydrick, who
>> are implementing similar functionality. But it is also a specification
>> that should feel right for Chef users, so every piece of feedback is
>> welcome!
>>
>> Cheers,
>> Miquel
>>
>
>
>
> --
> πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
> [The fox knows many things, but the hedgehog knows one big thing.]
>   Archilochus, Greek poet (c. 680 BC – c. 645 BC)
> http://wiki.hedgehogshiatus.com
>



Archive powered by MHonArc 2.6.16.

§