On Tuesday, January 27, 2015 at 9:36:35 AM UTC-6, Dave Jablonski wrote:
>
> I am trying to generate separate jndi.xml files for a mule_config module
> I'm building. Current setup:
>
>
Much of what you say seems quite reasonable, but bits of it are enough off
to make me scratch my head, starting with the title's reference to
non-nesting. How would nested defined types help here anyway? In any
case, do note that consensus best practice is to avoid nesting defined
types or other classes inside classes, too. Each class or defined type
should reside in its own file.
> Filesystem setup:
> /opt/mule-instance-a/conf/jndi.xml
> /opt/mule-instance-b/conf/jndi.xml
> etc, etc
>
>
> Currently I have created a defined type named mule_config to create the
> /opt/mule-instance-a directory structure and configuration.
>
> # Create the mule instance config files and create directories
> define mule::mule_config(
> #param list
> ){
>
> ##Shortened to just this stanza
> file { "/opt/${instance}/conf/jndi.xml":
> ensure => file,
> owner => 'tomcat',
> group => 'tomcat',
> mode => '0660',
> content => template("pg/${jndi_env}${instance}-jndi.xml.erb")
> }
> }
>
>
I'm not sure I follow why you need a different template for each instance.
I suppose it must mean that the target contents differ in structure, so
that you could not transform one to the other simply by substituting one
set of data for another. In that case, however, you are still generating
all the content of each file from input data of the same form, so it's
unclear what the issue is.
> My profile::mule looks like this:
> class profile::mule {
> $mule_instances = hiera('mule_instances', [])
> create_resources( 'pg::mule_config', $mule_instances )
> }
>
>
> Here's my sanitized hiera:
> mule_instances:
> mule-instance-a:
> instance: "mule-instance-a"
> mule-instance-b:
> instance: "mule-instance-b"
>
>
> What I would like to do is create the jndi.xml dynamically instead of
> using a separate template file for each instance. The jndi.xml file has
> repeatable elements (queues, jdbc connections, property map keys) that I
> would like to use the concat module and other create_resources defined
> types to build and use as the input to the /opt/${instance}/conf/jndi.xml
> file.
>
I think the Concat module is probably a sub-optimal direction for this.
Concat is most useful when the declarations and data from which the target
file is to be constructed are decentralized across multiple modules or
multiple target nodes. On the other hand, when everything about the target
file is managed by one module, based on the data applicable to the target
node and no others, you are probably better off just templating. It is
quite possible to structure your data so that one well-designed template
serves equally well for all your mule instances.
> I have created a mule_jndi class that does this but I'm not sure how to
> pass some parameters to it from the create_resources('pg::mule_config)
> defined type that it needs
>
Stop. Declarations evaluated by a class, whether literal or via
create_resources(), are not inputs to that class, they are outputs.
Moreover, declared resource instances cannot be queried as data sources.
> and use it as input to the file resource in the calling defined type.
> Basically I'm trying to use create_resources to create a jndi.xml file
> that becomes the input to the file resource in the mule_config defined
> resource.
>
>
Nope. Your class can do multiple things with the data that are provided as
input to create_resources(), but it cannot consume the outputs of
create_resources().
> Here's my mule_jndi class that concats a jndi.xml file to /tmp/jndi
>
[...]
Structure your data so that they are suitable for a general template to use
to create your jndi.xml. Use nested hashes and/or arrays to model
repeatable elements where the number of repeats varies from one instance to
another. Use Ruby loops in your template to transform those repeated data
into repeated JNDI elements. Your module will be much simpler and more
reliable, and yet your data -- though perhaps structured differently --
will be no more complex than you already envision.
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/a1405d40-bf91-418a-96fb-1fde62c1b163%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
