[Thincrust-devel] Re: RFC: Customizing an appliance install

[Bryan Kearney]

Brenton Leanhardt wrote:
> +++ Bryan Kearney [26/09/08 15:06 -0400]:
>> I am looking for feedback on how to customize an appliance install. As 
>> you may be aware, the appliance configuration engine uses puppet as 
>> it's configuration syntax. The rational is that this is an up and 
>> coming standard syntax, and should be familiar to those who do 
>> sysadmin type work (Said another way, we don't need yet another DSL).
>>
>> The trick is how to allow a user (either via the gui or the command 
>> line) to customize an appliance recipe. In puppet I have seen 2 ways 
>> to push in custom information:
>>
>> 1) External Nodes
>> 2) Facter
>>
>> I am thinking of using the latter, and would like to outline my 
>> thoughts. Please feel free to offer up alternative solutions.
>>
>> Goal:
>>
>> Create recipes which can externalize a small set of data which the 
>> user needs to provide in order to the appliance to be configured.
>>
>> Implementation
>>
>> A module, or a recipe can deliver one or more "external facts". They 
>> will be delivered in the form:
>>
>> name:default_value:query_text
> 
> This seems good to me.  In fact similar to how Genome's "machine type"
> DSL generates parameters for external nodes.  One thing I've thought
> about, that I think could be a better approach, is storing this sort
> of information in a special syntax (probably embedded in comments
> JavaDoc style) so that this information would ship with the module as
> opposed to keeping it in a separate file.

Yeah.. I think this is a good way to go. Keeping the number of files to 
a minimum would be good. Do you have a syntax chart for the genome DSL?


> When tooling like Thin Crust needs access to this sort of information
> there could be a Puppet tool that provides a way to collect it (ie, a
> way that understands how Puppet loads and finds modules).  Genome has
> had a hard time keeping a config file that represents
> "name:default_value:query_text" type information in sync with a large
> group of Puppet modules.  Especially when 15+ people have their hands
> in the modules.

That was what I was going to look to facter too. I do not believe this 
feature would be embraced by the puppet project in general.. so the 
easiest way to glom on would be the best.

-- bk