I created pull requests on the Vagrant issue
(https://github.com/mitchellh/vagrant/issues/1253). Chime in with your
opinions and comments!
On Saturday, December 8, 2012 at 19:05, Cassiano Leal wrote:
I wonder if we can close the one in Berkshelf.
On Saturday, December 8, 2012 at 16:08, Jamie Winsor wrote:
It probably is more appropriate to put it into Vagrant’s chef_client
On Saturday, December 8, 2012 at 7:16 AM, Cassiano Leal wrote:
I see that you opened that ticket on Berkshelf, but wouldn’t it make more
sense if Vagrant’s chef_client provisioner would do that job instead? After
all, it’s Vagrant who creates the client and node in the Chef server.
On Friday, December 7, 2012 at 22:58, Jamie Winsor wrote:
Here is the ticket: https://github.com/RiotGames/berkshelf/issues/264
On Friday, December 7, 2012 at 3:48 PM, Cassiano Leal wrote:
Wow, thanks for the enlightening answer Daniel, that’s exactly the sort of
thing I wanted to understand. I’ll study both approaches before I decide
which one to go with.
Jamie: Ridley looks great, thanks for writing that. Also yeah, I’m using
Berkshelf, and having that sort of functionality built into Vagrant would be
fantastic. Let me know the ticket number when you create it so that I can
chime in, if you don’t mind!
Adam: that comment made my afternoon!
On Friday, December 7, 2012 at 18:24, Daniel DeLeo wrote:
On Friday, December 7, 2012 at 11:29 AM, Adam Jacob wrote:
Use the REST api like a boss, man. That’s what it is there for.
On 12/7/12 10:17 AM, “Cassiano Leal” firstname.lastname@example.org wrote:
It would be nice to know the reasoning behind not using the REST client.
The higher up the chain you go, the more places we have to hide changes from
you. For example, we’d like to some day remove the json_class stuff from the
API, which means that the data you get back from Chef::REST will probably be
a Hash instead of a Chef::Node (or whatever you asked for). If (continuing
the example) you use the methods on Chef::Node, you wouldn’t be impacted by
this. Contrarily, the higher up the chain you go, there’s more things that
could be changed. As a concrete example, the #save method is defined on all
of the model classes to try to update and then fall back to create (or vice
versa, it’s not 100% consistent). We’d like to change this at some point so
there are separate create and update methods since 99% of the time you know
which one you need.
Either way, changes to the API or to core model class functionality are
generally only going to be shipped with major releases (e.g., 10.x -> 11.x)
and we’ll do our best to document them and announce them ahead of time on
this mailing list (upcoming changes in Chef 11, for example:
In conclusion, there are trade-offs either way, but both ways are valid.