Announcing Little Chef


#1

Hi Chefs!

I would like to present Little Chef, a new project that integrates with Chef.

LittleChef is actually an offspring of The Overmind, which was released a
couple of weeks ago
(http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201010.mbox/<AANLkTinZ-i0CoQABkdhA=E+veYhYrQh4sWLQtxDaWXPY@mail.gmail.com>).
Overmind aims to be a complete server management application. The first release
features server provisioning, and we want to tackle Configuration Management
next. We have decided on Chef, but as The Overmind wants to know everything
about its minions, we won’t be using Chef Server.

To explore the possibility of just using Chef Solo, LittleChef was born. It is
a tiny framework that replaces a subset of the functionality of Chef Server
using a push-based system.

Instead of needing a server to let your nodes pull info from, recipes are
automatically “pushed” to nodes every time you want to configure them. You
install LittleChef on your desktop/laptop, and work in “kitchens”
(deployment directories), where you have a cookbooks dir, a roles dir and a
nodes dir. That’s it.

Right now, in version 0.1 LittleChef:

* Allows to apply a recipe or role to a particular node   
* Saves recipes, roles and attributes for every node in configuration

files, which can afterwards be edited to override attributes
* Updates cookbooks on every node automagically, without the need for repo
syncing
* Can reconfigure every node
* Understands simple queries like showing all nodes with particular recipes
* Can’t bake cookies yet

There is an extensive README explaining installation and usage details.

FAQ
Q: “Wait, wait, did the world really need this duplication of efforts?”
A: “You are right. I am very sorry that I deprived the world of a couple of
hours of my precious hacking time to code those 200 lines of code. I hope the
world doesn’t mourn such a devastating loss for too long.”

Yes, you read that right. The whole thing is just a 200 lines of Python code.

Yes, you read that right. It is written in Python.

Python talking to Ruby. Yes, I am crazy and hope that this is the beginning of
a beautiful friendship.

The repo site: (http://github.com/tobami/littlechef)

Now, what is my purpose with this weird project besides experimenting and why
do I think anyone would be interested?

LittleChef is in essence a Pocket Chef (sadly an already registered trademark).
There are three areas in which a Pocket Chef could be useful:

* For newbies: Newcomers can have a hard time getting Chef running for the

first time, specially if they are evaluating other alternatives and have little
time, and even harder if they don’t have an inkling of Ruby. In the docs you
rightly recommend to get your feet wet with Chef Solo first, thus avoiding all
the Chef Server set-up/authentication overhead. But there are still to many
things to figure out at once. You should ideally only have to figure out a
single thing: how a cookbook works (and gets executed). With LittleChef, you
download the project to a directory on your computer and are immediately ready
to go. There is even a chef-solo deployment script that fetches opscode
packages for various distributions.
* For development: while developing new cookbooks, you can currently edit
recipes at your working system, check-in changes and have the chef-clients
execute the new version of the cookbooks. That is not an optimal work-flow,
because you end-up checking in small or experimental changes. With LittleChef
you develop cookbooks at your LittleChef/cookbooks/ directory, certainly under
source control. When you make changes and want to try them out, you just
execute “fab host:hostname recipe:mynewrecipe”. The cookbooks dir will get
gzipped, uploaded to the node, and the recipe run by chef-solo. When your
recipe has attained “delicious” status, you can then check in your changes.
Note that this is not incompatible with using Shef.
* For very small deployments: LittleChef will never be a full replacement
for the Chef server. A push architecture and configuration file is not the
right way to manage lots of servers. I can imagine though, small organizations
managing small numbers of servers (1-6) using LittleChef, thus avoiding the
need for a Chef server. They would possibly not have even considered using
Chef, but in this way they can manage their servers “the right way “(with a
CMS!) from the start.

This project, and even more a possible integration of Chef into Overmind, have
only been possible because of some great design decisions in Chef development:

* Having chef-solo in addition to chef-client
* Using json as the input/command issuing format, which removes language

barriers
* In cookbooks, having attributes you can override listed in json format
will allow for even more powerful integration.

I have a couple of suggestions so that Chef can remain a component other
projects can integrate seamlessly:

* Cookbooks: always clearly mark what cookbooks cannot be run without a

Chef server. Even better: always make them work without a chef server, by
listing the dynamic attributes in metadata.json and attributes/default.rb
* In general, continue considering Chef Solo a first-class citizen. That
means lots of little things like for example not starting the chef-client
service on package installation, so that chef-solo users don’t have to disable
the chef-client service every time after installation (which happens for
debian, but is done right for RHEL and CentOS)

Happy cooking, and careful with those nodes!
Remember, although a famous Chef used to say that “Anyone can cook”,
Little Chef says:
“Yeah. Anyone can, that doesn’t mean that anyone should”.

Miquel Torres


#2

Now if we had a way to “fake” databags this would be perfect…


#3

This is great to see, Miquel. For the record, we’re all about people
using Chef to fit the workflow they want most. :slight_smile:

As for Solo being a first class citizen, it certainly is for Opscode -
the difference is that, unlike the client/server model, it isn’t the
way we run our infrastructure day to day. I would love to see folks
who care deeply about Solo become more active in development, so that
we can make sure you’re needs are getting met.

Nice work!

Adam

On Wed, Oct 27, 2010 at 6:34 AM, tobami@googlemail.com wrote:

Hi Chefs!

I would like to present Little Chef, a new project that integrates with Chef.

LittleChef is actually an offspring of The Overmind, which was released a
couple of weeks ago
(http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201010.mbox/<AANLkTinZ-i0CoQABkdhA=E+veYhYrQh4sWLQtxDaWXPY@mail.gmail.com>).
Overmind aims to be a complete server management application. The first release
features server provisioning, and we want to tackle Configuration Management
next. We have decided on Chef, but as The Overmind wants to know everything
about its minions, we won’t be using Chef Server.

To explore the possibility of just using Chef Solo, LittleChef was born. It is
a tiny framework that replaces a subset of the functionality of Chef Server
using a push-based system.

Instead of needing a server to let your nodes pull info from, recipes are
automatically “pushed” to nodes every time you want to configure them. You
install LittleChef on your desktop/laptop, and work in “kitchens”
(deployment directories), where you have a cookbooks dir, a roles dir and a
nodes dir. That’s it.

Right now, in version 0.1 LittleChef:

  • Allows to apply a recipe or role to a particular node
  • Saves recipes, roles and attributes for every node in configuration
    files, which can afterwards be edited to override attributes
  • Updates cookbooks on every node automagically, without the need for repo
    syncing
  • Can reconfigure every node
  • Understands simple queries like showing all nodes with particular recipes
  • Can’t bake cookies yet

There is an extensive README explaining installation and usage details.

FAQ
Q: “Wait, wait, did the world really need this duplication of efforts?”
A: “You are right. I am very sorry that I deprived the world of a couple of
hours of my precious hacking time to code those 200 lines of code. I hope the
world doesn’t mourn such a devastating loss for too long.”

Yes, you read that right. The whole thing is just a 200 lines of Python code.

Yes, you read that right. It is written in Python.

Python talking to Ruby. Yes, I am crazy and hope that this is the beginning of
a beautiful friendship.

The repo site: (http://github.com/tobami/littlechef)

Now, what is my purpose with this weird project besides experimenting and why
do I think anyone would be interested?

LittleChef is in essence a Pocket Chef (sadly an already registered trademark).
There are three areas in which a Pocket Chef could be useful:

  • For newbies: Newcomers can have a hard time getting Chef running for the
    first time, specially if they are evaluating other alternatives and have little
    time, and even harder if they don’t have an inkling of Ruby. In the docs you
    rightly recommend to get your feet wet with Chef Solo first, thus avoiding all
    the Chef Server set-up/authentication overhead. But there are still to many
    things to figure out at once. You should ideally only have to figure out a
    single thing: how a cookbook works (and gets executed). With LittleChef, you
    download the project to a directory on your computer and are immediately ready
    to go. There is even a chef-solo deployment script that fetches opscode
    packages for various distributions.
  • For development: while developing new cookbooks, you can currently edit
    recipes at your working system, check-in changes and have the chef-clients
    execute the new version of the cookbooks. That is not an optimal work-flow,
    because you end-up checking in small or experimental changes. With LittleChef
    you develop cookbooks at your LittleChef/cookbooks/ directory, certainly under
    source control. When you make changes and want to try them out, you just
    execute “fab host:hostname recipe:mynewrecipe”. The cookbooks dir will get
    gzipped, uploaded to the node, and the recipe run by chef-solo. When your
    recipe has attained “delicious” status, you can then check in your changes.
    Note that this is not incompatible with using Shef.
  • For very small deployments: LittleChef will never be a full replacement
    for the Chef server. A push architecture and configuration file is not the
    right way to manage lots of servers. I can imagine though, small organizations
    managing small numbers of servers (1-6) using LittleChef, thus avoiding the
    need for a Chef server. They would possibly not have even considered using
    Chef, but in this way they can manage their servers “the right way “(with a
    CMS!) from the start.

This project, and even more a possible integration of Chef into Overmind, have
only been possible because of some great design decisions in Chef development:

  • Having chef-solo in addition to chef-client
  • Using json as the input/command issuing format, which removes language
    barriers
  • In cookbooks, having attributes you can override listed in json format
    will allow for even more powerful integration.

I have a couple of suggestions so that Chef can remain a component other
projects can integrate seamlessly:

  • Cookbooks: always clearly mark what cookbooks cannot be run without a
    Chef server. Even better: always make them work without a chef server, by
    listing the dynamic attributes in metadata.json and attributes/default.rb
  • In general, continue considering Chef Solo a first-class citizen. That
    means lots of little things like for example not starting the chef-client
    service on package installation, so that chef-solo users don’t have to disable
    the chef-client service every time after installation (which happens for
    debian, but is done right for RHEL and CentOS)

Happy cooking, and careful with those nodes!
Remember, although a famous Chef used to say that “Anyone can cook”,
Little Chef says:
“Yeah. Anyone can, that doesn’t mean that anyone should”.

Miquel Torres


Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com


#4

Sent from my iPad

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…

Yes. And fake them for chef-solo too. Could be as simple as a “databag” json-node in the json-tree


#5

You should call it petitechef
On Oct 27, 2010 6:38 PM, “Haselwanter Edmund” edmund@haselwanter.com
wrote:

Sent from my iPad

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…

Yes. And fake them for chef-solo too. Could be as simple as a "databag"
json-node in the json-tree


#6

Oh, I haven’t look into databags yet, I’m kind of a Chef newbie you know?

I’ll think about it for sure for next version!

2010/10/27 Brian Akins brian@akins.org:

Now if we had a way to “fake” databags this would be perfect…


#7

Hi Adam,

As for Solo being a first class citizen, it certainly is for Opscode -
well, I didn’t doubt that. That is why in my suggestions I knowingly wrote:
“In general, continue considering Chef Solo a first-class citizen”
:wink:

Nice to see you care about this kind of use cases.

Also, if many of you find it useful, we could set up a wiki page for
Chef newbies to get started the Little Chef way. I think some people
would find that easier.

Another thing. I read some comments on the possibility of a Python
bridge for cookbooks. I can not even begin to express how cool that
would be. Little Chef being in the Python Package Index could already
bring Chef new exposure to the Python devops world. If you add to that
Python cookbooks, well, Chef would have the potential of becoming
the Configuration Management system, across language and culture
divides. I would certainly contribute lots of Python cookbook
"translations"!

Cheers,
Miquel

2010/10/27 Adam Jacob adam@opscode.com:

This is great to see, Miquel. For the record, we’re all about people
using Chef to fit the workflow they want most. :slight_smile:

As for Solo being a first class citizen, it certainly is for Opscode -
the difference is that, unlike the client/server model, it isn’t the
way we run our infrastructure day to day. I would love to see folks
who care deeply about Solo become more active in development, so that
we can make sure you’re needs are getting met.

Nice work!

Adam

On Wed, Oct 27, 2010 at 6:34 AM, tobami@googlemail.com wrote:

Hi Chefs!

I would like to present Little Chef, a new project that integrates with Chef.

LittleChef is actually an offspring of The Overmind, which was released a
couple of weeks ago
(http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201010.mbox/<AANLkTinZ-i0CoQABkdhA=E+veYhYrQh4sWLQtxDaWXPY@mail.gmail.com>).
Overmind aims to be a complete server management application. The first release
features server provisioning, and we want to tackle Configuration Management
next. We have decided on Chef, but as The Overmind wants to know everything
about its minions, we won’t be using Chef Server.

To explore the possibility of just using Chef Solo, LittleChef was born. It is
a tiny framework that replaces a subset of the functionality of Chef Server
using a push-based system.

Instead of needing a server to let your nodes pull info from, recipes are
automatically “pushed” to nodes every time you want to configure them. You
install LittleChef on your desktop/laptop, and work in “kitchens”
(deployment directories), where you have a cookbooks dir, a roles dir and a
nodes dir. That’s it.

Right now, in version 0.1 LittleChef:

  • Allows to apply a recipe or role to a particular node
  • Saves recipes, roles and attributes for every node in configuration
    files, which can afterwards be edited to override attributes
  • Updates cookbooks on every node automagically, without the need for repo
    syncing
  • Can reconfigure every node
  • Understands simple queries like showing all nodes with particular recipes
  • Can’t bake cookies yet

There is an extensive README explaining installation and usage details.

FAQ
Q: “Wait, wait, did the world really need this duplication of efforts?”
A: “You are right. I am very sorry that I deprived the world of a couple of
hours of my precious hacking time to code those 200 lines of code. I hope the
world doesn’t mourn such a devastating loss for too long.”

Yes, you read that right. The whole thing is just a 200 lines of Python code.

Yes, you read that right. It is written in Python.

Python talking to Ruby. Yes, I am crazy and hope that this is the beginning of
a beautiful friendship.

The repo site: (http://github.com/tobami/littlechef)

Now, what is my purpose with this weird project besides experimenting and why
do I think anyone would be interested?

LittleChef is in essence a Pocket Chef (sadly an already registered trademark).
There are three areas in which a Pocket Chef could be useful:

  • For newbies: Newcomers can have a hard time getting Chef running for the
    first time, specially if they are evaluating other alternatives and have little
    time, and even harder if they don’t have an inkling of Ruby. In the docs you
    rightly recommend to get your feet wet with Chef Solo first, thus avoiding all
    the Chef Server set-up/authentication overhead. But there are still to many
    things to figure out at once. You should ideally only have to figure out a
    single thing: how a cookbook works (and gets executed). With LittleChef, you
    download the project to a directory on your computer and are immediately ready
    to go. There is even a chef-solo deployment script that fetches opscode
    packages for various distributions.
  • For development: while developing new cookbooks, you can currently edit
    recipes at your working system, check-in changes and have the chef-clients
    execute the new version of the cookbooks. That is not an optimal work-flow,
    because you end-up checking in small or experimental changes. With LittleChef
    you develop cookbooks at your LittleChef/cookbooks/ directory, certainly under
    source control. When you make changes and want to try them out, you just
    execute “fab host:hostname recipe:mynewrecipe”. The cookbooks dir will get
    gzipped, uploaded to the node, and the recipe run by chef-solo. When your
    recipe has attained “delicious” status, you can then check in your changes.
    Note that this is not incompatible with using Shef.
  • For very small deployments: LittleChef will never be a full replacement
    for the Chef server. A push architecture and configuration file is not the
    right way to manage lots of servers. I can imagine though, small organizations
    managing small numbers of servers (1-6) using LittleChef, thus avoiding the
    need for a Chef server. They would possibly not have even considered using
    Chef, but in this way they can manage their servers “the right way “(with a
    CMS!) from the start.

This project, and even more a possible integration of Chef into Overmind, have
only been possible because of some great design decisions in Chef development:

  • Having chef-solo in addition to chef-client
  • Using json as the input/command issuing format, which removes language
    barriers
  • In cookbooks, having attributes you can override listed in json format
    will allow for even more powerful integration.

I have a couple of suggestions so that Chef can remain a component other
projects can integrate seamlessly:

  • Cookbooks: always clearly mark what cookbooks cannot be run without a
    Chef server. Even better: always make them work without a chef server, by
    listing the dynamic attributes in metadata.json and attributes/default.rb
  • In general, continue considering Chef Solo a first-class citizen. That
    means lots of little things like for example not starting the chef-client
    service on package installation, so that chef-solo users don’t have to disable
    the chef-client service every time after installation (which happens for
    debian, but is done right for RHEL and CentOS)

Happy cooking, and careful with those nodes!
Remember, although a famous Chef used to say that “Anyone can cook”,
Little Chef says:
“Yeah. Anyone can, that doesn’t mean that anyone should”.

Miquel Torres


Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com


#8

Well, here is someone that needs to watch a certain Pixar movie
somewhat related to cooking :smiley:

2010/10/28 sahil.cooner@gmail.com sahil.cooner@gmail.com:

You should call it petitechef

On Oct 27, 2010 6:38 PM, “Haselwanter Edmund” edmund@haselwanter.com
wrote:

Sent from my iPad

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…

Yes. And fake them for chef-solo too. Could be as simple as a "databag"
json-node in the json-tree


#9

Ok, I had a look at databags. I could implement them in Little Chef,
and when calling chef-solo “merge” the data in the bags with recipe
attributes and pass it in a merged node.json file. But that is
complicating things a bit too much, and behaviour would not be
guaranteed to be identical to a Chef Server.

The best thing would be if it were implemented in Chef Solo itself.
You would call chef-solo in the same way as now, but cookbooks would
be able to use databags stored locally in “/tmp/chef-solo/databags/”

What do you think? Are there any prospects of that happening?

2010/10/28 Haselwanter Edmund edmund@haselwanter.com:

Sent from my iPad

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…

Yes. And fake them for chef-solo too. Could be as simple as a “databag” json-node in the json-tree


#10

I like that idea and am happy to hack on it.

On Thu, Oct 28, 2010 at 7:07 AM, Miquel Torres tobami@googlemail.comwrote:

Ok, I had a look at databags. I could implement them in Little Chef,
and when calling chef-solo “merge” the data in the bags with recipe
attributes and pass it in a merged node.json file. But that is
complicating things a bit too much, and behaviour would not be
guaranteed to be identical to a Chef Server.

The best thing would be if it were implemented in Chef Solo itself.
You would call chef-solo in the same way as now, but cookbooks would
be able to use databags stored locally in “/tmp/chef-solo/databags/”

What do you think? Are there any prospects of that happening?

2010/10/28 Haselwanter Edmund edmund@haselwanter.com:

Sent from my iPad

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…

Yes. And fake them for chef-solo too. Could be as simple as a "databag"
json-node in the json-tree


#11

Hi again,

I was thinking that LittleChef has a single limitation for its
intended use: if you have too many cookbooks it will be slow to push
all of them to a node. So I went ahead this morning and rewrote that
part. It now mimics Chef Server. It looks for recipes being directly
applied + recipes in the roles being applied + dependencies, and sends
only those to the node.

I have released the new version as 0.2.1, with a couple more fixes and niceties.

Now it is not a problem to clone and work with the whole
opscode/cookbooks repo :wink:

Cheers,
Miquel

2010/10/27 tobami@googlemail.com:

Hi Chefs!

I would like to present Little Chef, a new project that integrates with Chef.

LittleChef is actually an offspring of The Overmind, which was released a
couple of weeks ago
(http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201010.mbox/<AANLkTinZ-i0CoQABkdhA=E+veYhYrQh4sWLQtxDaWXPY@mail.gmail.com>).
Overmind aims to be a complete server management application. The first release
features server provisioning, and we want to tackle Configuration Management
next. We have decided on Chef, but as The Overmind wants to know everything
about its minions, we won’t be using Chef Server.

To explore the possibility of just using Chef Solo, LittleChef was born. It is
a tiny framework that replaces a subset of the functionality of Chef Server
using a push-based system.

Instead of needing a server to let your nodes pull info from, recipes are
automatically “pushed” to nodes every time you want to configure them. You
install LittleChef on your desktop/laptop, and work in “kitchens”
(deployment directories), where you have a cookbooks dir, a roles dir and a
nodes dir. That’s it.

Right now, in version 0.1 LittleChef:

  • Allows to apply a recipe or role to a particular node
  • Saves recipes, roles and attributes for every node in configuration
    files, which can afterwards be edited to override attributes
  • Updates cookbooks on every node automagically, without the need for repo
    syncing
  • Can reconfigure every node
  • Understands simple queries like showing all nodes with particular recipes
  • Can’t bake cookies yet

There is an extensive README explaining installation and usage details.

FAQ
Q: “Wait, wait, did the world really need this duplication of efforts?”
A: “You are right. I am very sorry that I deprived the world of a couple of
hours of my precious hacking time to code those 200 lines of code. I hope the
world doesn’t mourn such a devastating loss for too long.”

Yes, you read that right. The whole thing is just a 200 lines of Python code.

Yes, you read that right. It is written in Python.

Python talking to Ruby. Yes, I am crazy and hope that this is the beginning of
a beautiful friendship.

The repo site: (http://github.com/tobami/littlechef)

Now, what is my purpose with this weird project besides experimenting and why
do I think anyone would be interested?

LittleChef is in essence a Pocket Chef (sadly an already registered trademark).
There are three areas in which a Pocket Chef could be useful:

  • For newbies: Newcomers can have a hard time getting Chef running for the
    first time, specially if they are evaluating other alternatives and have little
    time, and even harder if they don’t have an inkling of Ruby. In the docs you
    rightly recommend to get your feet wet with Chef Solo first, thus avoiding all
    the Chef Server set-up/authentication overhead. But there are still to many
    things to figure out at once. You should ideally only have to figure out a
    single thing: how a cookbook works (and gets executed). With LittleChef, you
    download the project to a directory on your computer and are immediately ready
    to go. There is even a chef-solo deployment script that fetches opscode
    packages for various distributions.
  • For development: while developing new cookbooks, you can currently edit
    recipes at your working system, check-in changes and have the chef-clients
    execute the new version of the cookbooks. That is not an optimal work-flow,
    because you end-up checking in small or experimental changes. With LittleChef
    you develop cookbooks at your LittleChef/cookbooks/ directory, certainly under
    source control. When you make changes and want to try them out, you just
    execute “fab host:hostname recipe:mynewrecipe”. The cookbooks dir will get
    gzipped, uploaded to the node, and the recipe run by chef-solo. When your
    recipe has attained “delicious” status, you can then check in your changes.
    Note that this is not incompatible with using Shef.
  • For very small deployments: LittleChef will never be a full replacement
    for the Chef server. A push architecture and configuration file is not the
    right way to manage lots of servers. I can imagine though, small organizations
    managing small numbers of servers (1-6) using LittleChef, thus avoiding the
    need for a Chef server. They would possibly not have even considered using
    Chef, but in this way they can manage their servers “the right way “(with a
    CMS!) from the start.

This project, and even more a possible integration of Chef into Overmind, have
only been possible because of some great design decisions in Chef development:

  • Having chef-solo in addition to chef-client
  • Using json as the input/command issuing format, which removes language
    barriers
  • In cookbooks, having attributes you can override listed in json format
    will allow for even more powerful integration.

I have a couple of suggestions so that Chef can remain a component other
projects can integrate seamlessly:

  • Cookbooks: always clearly mark what cookbooks cannot be run without a
    Chef server. Even better: always make them work without a chef server, by
    listing the dynamic attributes in metadata.json and attributes/default.rb
  • In general, continue considering Chef Solo a first-class citizen. That
    means lots of little things like for example not starting the chef-client
    service on package installation, so that chef-solo users don’t have to disable
    the chef-client service every time after installation (which happens for
    debian, but is done right for RHEL and CentOS)

Happy cooking, and careful with those nodes!
Remember, although a famous Chef used to say that “Anyone can cook”,
Little Chef says:
“Yeah. Anyone can, that doesn’t mean that anyone should”.

Miquel Torres


#12

On 2010-10-28T03:40:18, Haselwanter Edmund wrote:

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…
Yes. And fake them for chef-solo too. Could be as simple as a “databag” json-node in the json-tree

Why are data bags needed in the first place (when attributes are
available)? Without support in chef-solo it fragments recipes.

/Allan

Allan Wind
Life Integrity, LLC
http://lifeintegrity.com


#13

I can see the value of having data bags being passed as a static json file to either chef-solo or littlechef. I just had a requirement pass my desk to build some nodes in a PCI environment that’s locked out from reaching our chef server and it would be a pain to have to redo a bunch of cookbooks that are dependent on data bags.

Consider this a +1 from me regarding this feature.


Ryan C. Creasey
Principal Systems Engineer
GameSpy Technology
IGN Entertainment

On Oct 28, 2010, at 8:44 AM, “Allan Wind” allan_wind@lifeintegrity.com wrote:

On 2010-10-28T03:40:18, Haselwanter Edmund wrote:

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…
Yes. And fake them for chef-solo too. Could be as simple as a “databag” json-node in the json-tree

Why are data bags needed in the first place (when attributes are
available)? Without support in chef-solo it fragments recipes.

/Allan

Allan Wind
Life Integrity, LLC
http://lifeintegrity.com


#14

I think of data bags as attributes of your whole infrastructure,
things that are not particular to any node or role. The cannonical
example is administrators and their private keys. In many (most?)
organizations, all of the admins have access to all of the boxes, so
this is global state that you want to manage in one place. I’m not
against having databag support for compatibility reasons in solo, but
it’s a little weird conceptually, since chef-solo is limited to a
single node view of the world.

If anyone is interested in writing databag support for chef-solo, feel
free to stop by #chef-hacking on freenode or ask on chef-dev if you
have questions about the code.

Dan DeLeo

On Thu, Oct 28, 2010 at 8:41 AM, Allan Wind
allan_wind@lifeintegrity.com wrote:

On 2010-10-28T03:40:18, Haselwanter Edmund wrote:

On 27.10.2010, at 18:19, Brian Akins brian@akins.org wrote:

Now if we had a way to “fake” databags this would be perfect…
Yes. And fake them for chef-solo too. Could be as simple as a “databag” json-node in the json-tree

Why are data bags needed in the first place (when attributes are
available)? Without support in chef-solo it fragments recipes.

/Allan

Allan Wind
Life Integrity, LLC
http://lifeintegrity.com


#15

On Thu, Oct 28, 2010 at 1:01 AM, Miquel Torres tobami@googlemail.com wrote:

Also, if many of you find it useful, we could set up a wiki page for
Chef newbies to get started the Little Chef way. I think some people
would find that easier.

Feel free.

Another thing. I read some comments on the possibility of a Python
bridge for cookbooks. I can not even begin to express how cool that
would be. Little Chef being in the Python Package Index could already
bring Chef new exposure to the Python devops world. If you add to that
Python cookbooks, well, Chef would have the potential of becoming
the Configuration Management system, across language and culture
divides. I would certainly contribute lots of Python cookbook
"translations"!

It’s been on the roadmap for a while, and all it really needs is
someone who wants to carry it over the finish line. Basically,
everything in Chef has a JSON representation - so you should be able
to translate from a Python based recipe DSL to resources in Chef, and
pass them back and forth - essentially passing the Run Context between
the Python process and the Ruby one. It means you wouldn’t have to
duplicate the work that already exists in the resources and providers,
and you would be able to write your own recipes, libraries, (and
potentially resources and providers as well) in the language of your
choice.

You can see a demo of doing this from Perl:

http://search.cpan.org/~holoway/Chef-0.01/lib/Chef.pm

Let me know if you want more insight.

Adam


Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com


#16

It’s been on the roadmap for a while, and all it really needs is
someone who wants to carry it over the finish line. Basically,
everything in Chef has a JSON representation - so you should be able
to translate from a Python based recipe DSL to resources in Chef, and
pass them back and forth - essentially passing the Run Context between
the Python process and the Ruby one. It means you wouldn’t have to
duplicate the work that already exists in the resources and providers,
and you would be able to write your own recipes, libraries, (and
potentially resources and providers as well) in the language of your
choice.

You can see a demo of doing this from Perl:

http://search.cpan.org/~holoway/Chef-0.01/lib/Chef.pm

That is very cool.
I have too many things on my plate right now, but it is good to know
that in principle it can be done… for when the time is right.

Miquel

2010/10/28 Adam Jacob adam@opscode.com:

On Thu, Oct 28, 2010 at 1:01 AM, Miquel Torres tobami@googlemail.com wrote:

Also, if many of you find it useful, we could set up a wiki page for
Chef newbies to get started the Little Chef way. I think some people
would find that easier.

Feel free.

Another thing. I read some comments on the possibility of a Python
bridge for cookbooks. I can not even begin to express how cool that
would be. Little Chef being in the Python Package Index could already
bring Chef new exposure to the Python devops world. If you add to that
Python cookbooks, well, Chef would have the potential of becoming
the Configuration Management system, across language and culture
divides. I would certainly contribute lots of Python cookbook
"translations"!

It’s been on the roadmap for a while, and all it really needs is
someone who wants to carry it over the finish line. Basically,
everything in Chef has a JSON representation - so you should be able
to translate from a Python based recipe DSL to resources in Chef, and
pass them back and forth - essentially passing the Run Context between
the Python process and the Ruby one. It means you wouldn’t have to
duplicate the work that already exists in the resources and providers,
and you would be able to write your own recipes, libraries, (and
potentially resources and providers as well) in the language of your
choice.

You can see a demo of doing this from Perl:

http://search.cpan.org/~holoway/Chef-0.01/lib/Chef.pm

Let me know if you want more insight.

Adam


Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com