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

[Bryan Kearney]

Brenton Leanhardt wrote:
> +++ Bryan Kearney [29/09/08 09:06 -0400]:
>> 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?
> 
> I've attached a sample config file.  You can see the code here:
> http://git.fedorahosted.org/git/genome.git?p=genome.git;a=tree;f=tools/genome-dsl;h=63b152ed2fca87bf47ebcae873c6ffe56fa87d96;hb=HEAD 


What do you think of this. Following the rdoc convention

# :default_value Foo
# :prompt What should the value of Foo be?
$variable = value_from_user()

This would result in a custom function which is executed at runtime to 
pull in the value (not polluting facter) and would feel somewhat rubyish.

-- bk