Hi again,
On Thu, Feb 11, 2010 at 11:12 AM, Frederik Wagner
<fner...@googlemail.com> wrote:
> On Thu, Feb 11, 2010 at 10:42 AM, Alan Barrett <a...@cequrux.com> wrote:
>> On Tue, 09 Feb 2010, Frederik Wagner wrote:
>>> I just tried using the define, and hit a problem which I would avoid
>>> (and actually need to avoid) by using the not implemented feature.
>>> Realizing the virtual define across modules forces me to give the
>>> namespace of the define explicitly, i.e. creating the virtual define
>>> @mymount in a class nas-1::virtual (in the Module nas-1) forces me to
>>> realize it in a second module as Nas-1::Virtual::Mymount<| |>, instead
>>> of just Mymount<| |>.
>>
>> Could you put the define in a common module, rather than a NAS-specific
>> module? For example:
>>
>> /* In the "util" module */
>>
>> define mymount ($mountpoint) {
>> realize File[$mountpoint]
>> mount { $mountpoint: require => File[$mountpoint], }
>> }
>>
>> /* In the nas-1::virtual class */
>>
>> @util::mymount { "foo": }
>>
>> /* Wherever you want to instantiate the mount: */
>>
>> include nas-1::virtual
>> realize Util::Mymount["foo"]
>
> yes, in principle, if it wouldn't be just for this generic Mymount
> definition. Mymount is somehow just an extended redifinition of mount
> where all parameters are passed.
>
> But besides the required file resource some very nas-1 specific
> editing in /etc/sysctl.conf etc. (via augeas) should be done.
> Therefore any Mymount (there are multiple mountspoint on that filer)
> should also realize an augeas resource which defenitly can not go into
> the Util module. Do you see what I mean? The nas-1 module would be
> like:
>
> @augeas{ very specifig editing }
>
> @file{ mountpoint }
>
> @mount{ mountpoint: require => [realize Augeas, realize File] }
>
> where - like you said - mount+file have a generic form which can end
> up in a definition in "Util" but augeas has to stay in "nas-1".
>
> As far as I see - and I was thinking quite a while about it - I really
> end up needing the realization by require feature :-( or it's going to
> be a intermodule dependency mess.
>
I found a working for this problem! I hope this will work in more
complicated situations.
I copied the code of the realize-function to be of :type => :rvalue,
just additionally returning the resources it realized.
In this way I can use it as a input for the 'require' parameter, like
@resource_one{ name: ... }
@resource_two{ name:... , require => new_realize( Resource_one[name] ) }
realize Resource_two[name]
This works perfect for this simple case, resource_one is realize
automatically and before resource_two. That should be it. I go on
testing in a more complicated setup.
So wouldn't be a simple idea to just change the realize function (or
the '<| ... |>' operator) to return the resources it realised?
Bye,
Frederik
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
