[chef] Re: Object-Oriented Chef

[Noah Kantrowitz < >]

On Sep 16, 2015, at 4:04 PM, Jos Backus 
<
 >
 wrote:

> Hi Noah,
> 
> 
> 
> On 9/16/15, 3:47 PM, "Noah Kantrowitz" 
> <
 >
>  wrote:
> 
>> 
>> On Sep 16, 2015, at 3:44 PM, Jos Backus 
>> <
 >
>>  wrote:
>> 
>>> Hi,
>>> 
>>> It would be nice if there was better support for the native Ruby Chef 
>>> classes/methods aside from the Chef::Recipe DSL with its fixed structure 
>>> of cookbooks/recipes, etc. It seems to me that with access to the 
>>> run_context class and the various resources, one could implement multiple 
>>> run/convergence queues easily enough (by instantiating different 
>>> run_contexts and operating on them), for example, and it would also open 
>>> up the ability to use traditional classes/modules for adding structure 
>>> and reusability, rather than the limited Chef::Recipe API. I understand 
>>> that the current DSL is concise, convenient for beginners and mimics what 
>>> Puppet uses, but it lacks structural power.
>> 
>> This is exactly what my Poise (https://github.com/poise/poise) library and 
>> John's Resource library do. This rabbit hole runs deep, happy to answer 
>> questions for you, though IRC (#chef on Freenode) might be a better medium.
> 
> Thanks for the quick reply!
> 
> Looking at Poise, I still see recipes and cookbooks, which means ultimately 
> we are still tied to the Chef::Recipe DSL. Iow, Poise seems to be an 
> alternative to writing LWRPs. Maybe I misunderstand?
> 
> What I’m interested in is a pure Ruby solution without cookbooks/recipes. I 
> want to write classes and modules with Chef::Resource::File.new (etc.) 
> calls, not `file “foo” do … end’. I think of the Chef DSL as one somewhat 
> convenient but not very powerful interface to the underlying Chef Resource 
> classes it fronts; one could use those classes independently of the DSL. 
> E.g.
> 
> run_context = Chef::RunContext.new(Chef::Node.new, {}, 
> Chef::EventDispatch::Dispatcher.new)
> 
> Chef::Resource::Directory.new(“/my_dir", run_context) do |res|
>  res.mode 0755
>  res.owner ‘root’
>  res.group ‘root’
>  res.run_action(:create)
> end
> 
> Chef::Resource::File.new(“/my_dir/foo", run_context) do |res|
>  res.mode 0644
>  res.owner ‘root’
>  res.group ‘root’
>  res.run_action(:create)
>  res.content = “some content"
> end
> 
> result = run_context.converge
> 
> 
> Of course the above could live in classes/modules as is normal with Ruby 
> code.
> 
> Hope this explains what I’m interested in a little better.

The DSL is used for convenience on declaring thought, though you could easily 
use code like you describe if you add `run_context.resource_collection <<` in 
there. Otherwise Poise is pretty literally what you describe. See 
https://github.com/poise/poise-service/blob/master/lib/poise_service/resources/poise_service_user.rb
 for an example. That also uses Halite which is a thing I wrote to let me 
write all my code as standard gems and convert them to cookbooks on the fly. 
The creation and management of nested converge cycles is a bit more complex 
than you describe, and I've bundled it all inside helper APIs like 
notifying_block. That method creates a nested run based on the code inside 
it. Like I said, this is a very complex topic and I would happily not spam 
the whole list all day if you have specific questions. You can find me as 
"coderanger" on IRC or HangOps Slack.

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail