|
inline
From: Ranjib Dey
Reply-To: " "> " Date: Wednesday, September 16, 2015 at 6:17 PM To: " "> " Subject: [chef] Re: Re: Re: Object-Oriented Chef inline responses
On Wed, Sep 16, 2015 at 5:07 PM, Jos Backus
<
" target="_blank">
> wrote:
awesome
yes. but as i said, cookbooks are different due to static contents & segment (gems have only ruby files and executables) In fact, when starting out with Chef a couple of months ago, I was very surprised to find that cookbooks could not nest arbitrarily.
yeah, .. there are several limitations.. all they just dont have all the joys of pure gems. use libraries to bridge.
[Jos] Sure, but cookbook-free Chef would be even better, no?
its per easy,,, o = Ohai::System.new. o.run_plugins. chef injects this data inside node object during startup, which appears as automatic attributes.
[Jos] Yes, that’s how it works.
right. i prefer instance eval, for the same reason we instance_eval on recipe.
[Jos] The downside of using instance_eval is that this
def meth
"bar"
end
ruby_block "foo" do
block do
puts "foo" + meth
end
end
doesn’t work. (Yes, I know how to work around this but that’s not the point.)
to me attributes are recipe parameters.
[Jos] It means that attributes become part of the method signature of each recipe, i.e. global state. Like this:
def foo
puts “Hi, #$attr”
end
$attr = “foo”
foo
$attr = “bar”
foo
It means that rather than being able to glance at the method signature to spot what a method can see, you have to look at all the attribute key paths as it’s one giant Hash (not even mentioning the complication of the various precedence levels, which personally
I feel is a design defect, but I’m sure that’s not a popular opinion around here :-) ). So in my opinion attributes are a poor substitute for proper parameterization.
Im sorry you feel limited, lets see if we can make this betters.
[Jos] Great, thanks! I appreciate your efforts. I do think Chef has great potential if the focus remains on the resource collection and ways to generate it (cookbooks and the Recipe DSL being just one way).
I think of chef as a generic infrastructure library in ruby. knife being the CLI front end, client being the implementation of CM pattern, chef server being a metadata source. Now, unless you need CM, you dont need the client bits, use the subsystem. In
past we have two question on the same line. First, what about a completely serializable DSL (i dont know if you can call that dsl), like yaml or json. Second, what if we have an explicit DSL, i.e. instead of instance_eval, we implement a class or something
similar. To me both of this two are two extremes. First one reduces composability (u are bound by the platform), while second on allow some composition but not with some quirks (certain things dont work :-)), which albeit is annoying from pure ruby perspective.
But remember theres nothing in Chef that prevent you from doing what you want. i,e. you can you cookbook syncer to grab things, and then build node, construct run list, execute it.
[Jos] Understood, with the caveat that I personally think that Chef would improve if it was less cookbook-centric. Maybe one of the reasons the current state of cookbooks is what it is because cookbooks with their global state and limited composability
(include_recipe is about it, and it takes no parameters) make it easy to write poor code? Yes, you can write LWRPs (or even native Ruby) but there the issue is that the community has so many options that it’s not clear what the way forward is, and it leads
to fragmentation and duplication of effort. I’d like to see the community converge (pun intended) on a single, well-supported easy to use LWRP solution at least. I don’t want to have to install the LWRP framework of the day just to be able to use some solution
someone has built using it because it was cool.
(Sorry for the slightly off-topic tangent.)
i dont which one is best (serializable files, implicit DSL of current chef, or explicit DSL, the one you are talking about). i'll be very interested to know others opinion. I see there are limited perf benefits, and a lot of ease for pure ruby devs. But
lot bigger learning curve for non-rubyist, and also a lot more verbosity. Unless your resource list is lot smaller than your all other logic (which is rarely the case, in my experience) explicit dsl will be pretty verbose.
[Jos] Yes, it will be verbose, like Java perhaps ;-) But I think the tradeoff in terms of composition power is worth it. You could even still have a Cookbook and a Recipe class if you prefer that structure, but skip the DSL.
it will be nice if you specify an use case instead, and we compare how you could have implemented it if explicit DSL was there, and then we share how currently we can do this. we can compare its lot easier that way
[Jos] Well, the current example I’m struggling with is that I’m trying to install two Java versions at the same time with the Oracle JCE components. but the recipes in that cookbook use a bunch of global state so even though I monkey patched the DSL with
include_recipe_again and I’m able to run the oracle_jce recipe twice, I have to figure out what node key paths it uses and set those before the include. This is a pain. Another issue I had is that in a recipe you can’t easily define methods and use them in
resource blocks, like I showed above (they have to be defined on the class or instance of the resource instead). This is cumbersome as well. I believe to me as someone who knows Ruby this would be more straightforward if it was all just Ruby to begin with.
Thanks again for your insights and comments.
Jos
|
Archive powered by MHonArc 2.6.16.