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

[Brenton Leanhardt]

+++ 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

>
>
>> 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
>
-------------- next part --------------
# Copyright (C) 2008 Red Hat, Inc

# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# a long with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

################################################################################
#Define new facts here. You can later map them to machine types in the         #
#following section.                                                            #
#                                                                              #
# One thing to note is the special syntax allowed when setting default values  #
# for facts.  In the default string you are allowed to use "%repo%" or         #
# "%machine_name%" which will get substituted appropriately whenever this data #
# is used (eg, genome-bootstrap uses this for setting context aware default    #
# values for facts).                                                           #
#                                                                              #
# If a fact needs to be on all machines types set ":on_all_nodes"              #
# appropriately.  Otherwise in the machine declaration section you need to     #
# specify what facts will be used for a particular machine.                    #
################################################################################
#
# A couple of example facts.
#
# newfact("logserver", :on_all_nodes => true) do
#   set_desc "The machine to send syslog output to"
#   set_default "%repo%-repo.usersys.redhat.com"
# end
#
# newfact("multiline_description") do
#   desc = <<END
# A description that just so happens to span
# multiple line.  Also, we want the line breaks
# to be preserved.  So, we use the "here 
# document" syntax.
# END
#   set_desc desc.chomp!
#   set_default "default_value"
# end
#
# 
##############################################################################
# Machines definitions go here. It is important that this happens after the  #
# fact declarations.  Aside from that, order does not matter.                #
##############################################################################
#
# classes_on_all_machine_types "genomerepo::client"
#
# newmachine("jboss-dev") do
#   include_facts "logserver"
#   set_classes "jboss::dev", "java", "jboss::server::web",
#               "mysql::standalone", "jboss::ds::messaging", "jboss::ds::esb",
#               "apache::ssl", "apache::ajp_http","apache::ajp_devel", 
# end