[chef-dev] Re: Re: Re: Re: Re: Dialect support and loading enhancements


Chronological Thread 
  • From: Noah Kantrowitz < >
  • To: Chef Dev < >
  • Subject: [chef-dev] Re: Re: Re: Re: Re: Dialect support and loading enhancements
  • Date: Wed, 2 Oct 2013 15:15:23 -0700


On Oct 2, 2013, at 3:09 PM, Noah Kantrowitz 
< >
 wrote:

> 
> On Oct 2, 2013, at 2:35 PM, Ranjib Dey 
> < >
>  wrote:
> 
>> i second dan's comment.  Examples that you have given are not dialects, 
>> they are more like rendering system. Salt has it already. Chef already has 
>> to_json/from_json and to_text support for resources (albeit the to_text 
>> method is buggy), so you should be able to  communicate with chef or use 
>> chef components as it is, as long as the other system is eating/spitting 
>> json. If you want to write a component in other language, why not take 
>> that route?
> 
> The "other system" in question is humans, and JSON is awesome as an 
> interchange format but not as nice for human-authored stuff.
> 
>
>> It makes more sense to make to json support in core chef more stable and 
>> extensible. 
>
>> Also i find it hard to understand that yaml or json is more readable than 
>> their ruby counterpart.  they look and feel readable in low volume, but  
>> at large scale, they are nightmare. they were meant for serialization, why 
>> you want to check them inside code base, when you can generate the same 
>> with smaller codebase using a language ?
>
> 
> 1) data bags don't have a Ruby DSL nor would that probably help much and 2) 
> there is some resistance to using the Ruby DSL for roles/envs because it 
> can't really be made compatible with knife diff, Yaml is somewhat of a 
> compromise there, as well as making it clearer that the data needs to be 
> fully declarative despite the ".rb".
> 
> If you mean for attribute files, I favor supporting Yaml there because it 
> covers the 99% use case for people with a syntax they are slightly more 
> likely to know. Ruby vs. Yaml on attribute files is super minor though, and 
> I'm happy to agree to disagree and relocate that stuff out to a cookbook (I 
> was planning on making a dialect-erbyaml cookbook anyway as a test case, so 
> the incremental work here is super tiny). I think it will fall to me to put 
> together some good documentation about what dialects exist and what use 
> cases the work well for, and I'll have to keep that updated as time goes on 
> and new dialects arise (I hope).

Just to add a bit to this, I think some of my worry is that internally Chef 
will have JSON dialect support for a few objects (metadata, roles, envs, data 
bags) but attributes are kiiiiind of a special case in that you need an 
external cookbook. Will need to figure out how to explain that difference.

--Noah

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




Archive powered by MHonArc 2.6.16.

§