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,
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
At first glance, I like it.
Adam
On Tue, May 17, 2011 at 7:43 AM, Miquel Torres tobami@googlemail.com 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,
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
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com
We like it too. We had a similar spec for what we were calling meta-chef that would do this and also handle things like scheduling when nodes would be operational. If we move forward with that project we'll be in touch with you guys to try to adhere to some standard.
Thanks,
-Kevin
-----Original Message-----
From: Adam Jacob [mailto:adam@opscode.com]
Sent: Tuesday, May 17, 2011 12:55 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Infrastructure Deployment Specification
At first glance, I like it.
Adam
On Tue, May 17, 2011 at 7:43 AM, Miquel Torres tobami@googlemail.com 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,
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
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com
It's funny you bring this up. I was just talking to someone on IRC not
longer after CloudFormation came out that we should work on getting a
common definition for that type of stack together. I'm behind the idea
100% and obviously it should include the other tools as well.
On Tue, May 17, 2011 at 10:43 AM, Miquel Torres tobami@googlemail.com 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,
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
On Wed, May 18, 2011 at 12:43 AM, Miquel Torres tobami@googlemail.com 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
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 hedgehogshiatus@gmail.com:
On Wed, May 18, 2011 at 12:43 AM, Miquel Torres tobami@googlemail.com 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