- 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.