Hi Folks, Like to get some advice on module organization. I have a system that has a few different components. One or more components can be installed on a host. The hosts also have a "type" dimension. This "type" dimension could (should) ideally be used to configure the system (fill in a bunch of variables). Problem is, I''m not sure how the best way to do this in puppet. I''m running puppet 2.7x. To illustrate, I''d like to do something like this (pseudo syntax): node ''foo.example.com'' { include module::component("systemType" => "foobar") include module::component2("systemType" => "foobar") } node ''foo2.example.com'' { include module::component("systemType" => "foobar2") include module::component3("systemType" => "foobar2") } or, maybe even better node ''foo.example.com'' { include module(components => [component1,component2], "systemType" => "foobar") } node ''foo2.example.com'' { include module(components => [component1,component3], "systemType" => "foobar2") } In the above illustration, the value of componentType can determine which files to load, as well as a bunch of variables (40-60 variables) which would be used for things like ensuring directories are present, ownership, users installed, etc.. I was thinking that each component would be a class, which is fine in itself, but my real problem is the movement of these variables (configuration). There are a lot of components, and enough variables that I don''t want to add them to each class. I want to be able to do something like: class mymodule(components, componentType) { $myconfig = getConfig($componentType) # can I "loop" through components? include mymodule::component($myconfig) } Hopefully that''s descriptive enough. Feel free to ask questions. Ultimately, my major goal is to boil the configuration down to a single location, as the configurations (systemTypes). Some like this would work (I think) if calling the class could be dynamic: http://docs.puppetlabs.com/guides/parameterized_classes.html#appendix-smart-parameter-defaults Thanks in advance for the feedback, Tom -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Hi Folks, Like to get some advice on module organization. I have a system that has a few different components. One or more components can be installed on a host. The hosts also have a "type" dimension. This "type" dimension could (should) ideally be used to configure the system (fill in a bunch of variables). Problem is, I''m not sure how the best way to do this in puppet. I''m running puppet 2.7x. To illustrate, I''d like to do something like this (pseudo syntax): node ''foo.example.com'' { include module::component("systemType" => "foobar") include module::component2("systemType" => "foobar") } node ''foo2.example.com'' { include module::component("systemType" => "foobar2") include module::component3("systemType" => "foobar2") } or, maybe even better node ''foo.example.com'' { include module(components => [component1,component2], "systemType" => "foobar") } node ''foo2.example.com'' { include module(components => [component1,component3], "systemType" => "foobar2") } In the above illustration, the value of componentType can determine which files to load, as well as a bunch of variables (40-60 variables) which would be used for things like ensuring directories are present, ownership, users installed, etc.. I was thinking that each component would be a class, which is fine in itself, but my real problem is the movement of these variables (configuration). There are a lot of components, and enough variables that I don''t want to add them to each class. I want to be able to do something like: class mymodule(components, componentType) { $myconfig = getConfig($componentType) # can I "loop" through components? include mymodule::component($myconfig) } Hopefully that''s descriptive enough. Feel free to ask questions. Ultimately, my major goal is to boil the configuration down to a single location, as the configurations (systemTypes). Some like this would work (I think) if calling the class could be dynamic: http://docs.puppetlabs.com/guides/parameterized_classes.html#appendix-smart-parameter-defaults Thanks in advance for the feedback, Tom -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Hi Tom, This definitely seems like a job for parameterized classes. This language feature allows you to define your model while expressing some parameters (data) that your model will use to modify its behavior. In your node definitions, you''d declare parameterized clases like resources. http://docs.puppetlabs.com/learning/modules2.html#parameters class { ''module::component'': systemtype => ''foobar'', } When it comes to ''looping'' through things, the Puppet DSL does not yet have an iterator or other like operators. We do have something called defined resource types. The end-result looks like a regular resource but it''s ''defined'' from a collection of other resource types that you can pass data into. It''s great for modeling something complex that you can interact with via a simplified resource interface. Here''s a doc on the subject: http://docs.puppetlabs.com/learning/definedtypes.html Once you have a defined resource type that gives you the looping behavior you''re looking for, I suggest that you ''declare'' one or more of these resources in your classes (like module::component). You can then use the parameterized class mechanism to pass in data to all the resources in your classes, including those that you have defined. Hope that makes sense and good luck! --Ryan On Thu, Mar 14, 2013 at 10:55 PM, Tom Melendez <tom@supertom.com> wrote:> Hi Folks, > > Like to get some advice on module organization. I have a system that > has a few different components. One or more components can be > installed on a host. The hosts also have a "type" dimension. This > "type" dimension could (should) ideally be used to configure the > system (fill in a bunch of variables). Problem is, I''m not sure how > the best way to do this in puppet. > > I''m running puppet 2.7x. > > To illustrate, I''d like to do something like this (pseudo syntax): > > node ''foo.example.com'' { > include module::component("systemType" => "foobar") > include module::component2("systemType" => "foobar") > } > > node ''foo2.example.com'' { > include module::component("systemType" => "foobar2") > include module::component3("systemType" => "foobar2") > } > > or, maybe even better > > node ''foo.example.com'' { > include module(components => [component1,component2], "systemType" > => "foobar") > } > > node ''foo2.example.com'' { > include module(components => [component1,component3], "systemType" > => "foobar2") > } > > In the above illustration, the value of componentType can determine > which files to load, as well as a bunch of variables (40-60 variables) > which would be used for things like ensuring directories are present, > ownership, users installed, etc.. > > I was thinking that each component would be a class, which is fine in > itself, but my real problem is the movement of these variables > (configuration). There are a lot of components, and enough variables > that I don''t want to add them to each class. I want to be able to do > something like: > > class mymodule(components, componentType) { > $myconfig = getConfig($componentType) > # can I "loop" through components? > include mymodule::component($myconfig) > } > > Hopefully that''s descriptive enough. Feel free to ask questions. > Ultimately, my major goal is to boil the configuration down to a > single location, as the configurations (systemTypes). Some like this > would work (I think) if calling the class could be dynamic: > > http://docs.puppetlabs.com/guides/parameterized_classes.html#appendix-smart-parameter-defaults > > Thanks in advance for the feedback, > > Tom > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- Ryan Coleman | Modules & Forge | @ryanycoleman | ryancoleman in #puppet -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On Saturday, March 16, 2013 9:49:24 AM UTC-5, Ryan Coleman wrote:> > Hi Tom, > > This definitely seems like a job for parameterized classes. This language > feature allows you to define your model while expressing some parameters > (data) that your model will use to modify its behavior. >Parameterized classes certainly provide a close match to the declaration style the OP proposed, but since he already seems aware of them, I would like to know why he is concerned that they may not be suitable. I suspect the key is in his desire that "calling the class could be dynamic", but I''m not sure what he means by that. Perhaps that the class(es) to be declared is chosen at runtime? Anyway, no job is appropriate for parameterized class declaration syntax (so the OP is right to be doubtful). Parameterized classes themselves are fine if data are bound via hiera (v3.0+ only), and maybe if they are bound via an ENC, but it is both conceptually and practically problematic to bind non-default data to classes via the DSL. There are several ways in which the problem could be addressed via hiera, both with and without parameterized class use. For example, if the system_type dimension is going to be declared at node level for all nodes, then I think it could be used to define a level of an Hiera hierarchy: ---:backends: - yaml:yaml: :datadir: /etc/puppet/hieradata :hierarchy: - %{system_type} - common Then configuration data would be recorded in YAML format in files (for example) /etc/puppet/hieradata/{common,foobar,foobar2}.yaml. Configured classes would obtain the data via calls to the hiera() function (since there is no automated data binding in Puppet 2.7), such as this: $myproperty = hiera(''my_property_name'') Furthermore, if an important point is to select components (classes) to declare based on system type, then the hiera_include() function fits the bill exactly: hiera_include(''classes_key'') Hiera is an add-on for Puppet 2.7, but it is integrated into the core starting with Puppet 3, so using it is forward-looking. With all that said, this whole thing could as easily go in a completely different direction. If we take a step back and look at the bigger picture the OP presents, his module organization question might be as well or better answered via Craig Dunn''s "Roles and Profiles" pattern (http://www.craigdunn.org/2012/05/239/). The OP''s "system type" concept seems an excellent match to Craig''s "role". That does not invalidate any of the foregoing comments, however, as hiera (and parameterized classes) are pretty much orthogonal to roles and profiles. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.