Which I think is only merged to master. If you're using Chef as a library in another application it should be fine to start from there (and super easy to do if you're using bundler).
I ended up creating a little monkeypatch for the rest client. This was
complicated a bit by having different Chef objects instantiate their own
REST client in subtly different ways...
In case it helps other folks still on 10.x, (and in case folk spot issues I
didn't...)
The idea is that once you "replace_authenticator", all future REST
instances will use the alternative client/key.
On Mon, Jan 7, 2013 at 1:48 PM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, January 7, 2013 at 10:41 AM, andi abes wrote:
Which I think is only merged to master. If you're using Chef as a library
in another application it should be fine to start from there (and super
easy to do if you're using bundler).
--
Daniel DeLeo
On Mon, Jan 7, 2013 at 1:32 PM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, January 7, 2013 at 10:14 AM, andi abes wrote:
I'm using the chef REST API client (in code), and I would like to provide
the signing key from somewhere other than the filesystem.
Looking at Chef::REST::AuthCredentials, I'm thinking of replacing the
load_signing_key by redefining the method.
Anyone else play with this? Any caveats?
Looks like you just need to pass :raw_key => true to Chef::REST.new
On Thursday, January 10, 2013 at 7:13 AM, andi abes wrote:
I ended up creating a little monkeypatch for the rest client. This was complicated a bit by having different Chef objects instantiate their own REST client in subtly different ways...
In case it helps other folks still on 10.x, (and in case folk spot issues I didn't...)
But as you alluded to, most of the model objects in Chef don't give you control over the rest client. I think it would be reasonable to add support for that if you're interested.