Conditional Require For File Type

[Jason Wever]

Hi All,

I having a problem in where I'm defining a File Type and setting the
requires parameter to use a variable name (e.g. requires => $foo).
However, when I do this, the Puppet run doesn't act like it's
translating the variable into what it should be set to. $foo should
resolve to either Class['a'] or Class['b'] depending on a particular
fact, but the File Type is being processed by Puppet before Class['a']
or Class['b'] has been processed.

Is it possible to use a variable as the value for the requires
parameter in a File Type?

I've tried this with Puppet versions 3.5.1 and 3.6.1 but no change in
behavior. Haven't tried a 3.7.x.

Thanks,
--
Jason Wever

[Felix Frank]

Hi,

this is not an ordering issue.

$foo = 'Class["a"]'

The above string is not blessed into a class reference when used as the
value for an ensure parameter (apparently). Not quoting it makes no
difference.

This should work:

$foo = "a"

File["/path/to/file"] { require => Class[$foo] }

HTH,
Felix

[jcbollinger]

On Wednesday, January 14, 2015 at 8:08:25 PM UTC-6, Felix.Frank wrote:

On 01/14/2015 03:47 PM, Jason Wever wrote:
> Hi All,
>
> I having a problem in where I'm defining a File Type and setting the
> requires parameter to use a variable name (e.g. requires => $foo).
> However, when I do this, the Puppet run doesn't act like it's
> translating the variable into what it should be set to.  $foo should
> resolve to either Class['a'] or Class['b'] depending on a particular
> fact, but the File Type is being processed by Puppet before Class['a']
> or Class['b'] has been processed.
>
> Is it possible to use a variable as the value for the requires
> parameter in a File Type?
>
> I've tried this with Puppet versions 3.5.1 and 3.6.1 but no change in
> behavior.  Haven't tried a 3.7.x.
>
> Thanks,

Hi,

this is not an ordering issue.

Perhaps not.

 

$foo = 'Class["a"]'

The above string is not blessed into a class reference when used as the
value for an ensure parameter (apparently). Not quoting it makes no
difference.

Are you sure that quoting vs. not quoting doesn't make a difference?  At least with the future parser, the unquoted version ought to be a bona fide class reference in any context, and I didn't think that was new.  Or are you suggesting that the reference gets stringified upon assignment to a variable?  I've never done much along these lines, but that sounds surprising and a bit inconsistent to me.

Or what about this:

$foo = [ Class['a'] ]

In any case, if $foo does not resolve to a class or resource reference, then why does catalog building succeed?  (Or perhaps the problem actually manifests as catalog building failure....)

 

This should work:

$foo = "a"

File["/path/to/file"] { require => Class[$foo] }

Yes, that should certainly work (provided that Class['a'] is declared for the node).  Depending on the availability of $foo, that approach might also be taken in the original File declaration instead of being performed as an override.  In fact, if it cannot be performed in the initial declaration, then it would be better to use the appropriate chain operator, to avoid the possibility of overriding other relationships set via 'require':

Class[$foo] -> File['/path/to/file']


John

[Henrik Lindberg]

The 3x catalog/resource API requires that type references are indeed
stringified. Internally that string is then turned into a Resource
instance where only type and title are filled in.

So, yeah, atm, there is no difference between a quoted reference and a
real resource type reference. There will be when we in a later version
of puppet improve the catalog and compiler (although the string type
will most likely still be supported, it will be more efficient to use a
type).

- henrik
--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Jason Wever]

On Thu, Jan 15, 2015 at 9:53 AM, jcbollinger <John.Bo...@stjude.org> wrote:
>
> In any case, if $foo does not resolve to a class or resource reference, then
> why does catalog building succeed? (Or perhaps the problem actually
> manifests as catalog building failure....)

Feels like I've been staring at the problem too long, forgetting to
provide a little more detail here.

When I have requires = $foo, the catalog does compile and $foo does
resolve to Class['a'] or Class['b'] correctly when I look at the debug
output from the Puppet agent (puppet agent -tv --debug).

If I use the anchor method as well ($foo -> Class['a]), it wasn't
installing it in the preferred order as well, but if I use the anchor
method on the Service Type that Class['a'] provides in its service.pp,
then it worked for me.

>> This should work:
>>
>> $foo = "a"
>>
>> File["/path/to/file"] { require => Class[$foo] }
>>

This method allowed the catalog to compile as well, but didn't change
any of the ordering issues.

Thanks for all of the replies and answers!

Cheers,
--
Jason Wever

[jcbollinger]

On Friday, January 16, 2015 at 12:48:19 PM UTC-6, Weeve wrote:

On Thu, Jan 15, 2015 at 9:53 AM, jcbollinger <John.Bo...@stjude.org> wrote:
>
> In any case, if $foo does not resolve to a class or resource reference, then
> why does catalog building succeed?  (Or perhaps the problem actually
> manifests as catalog building failure....)

Feels like I've been staring at the problem too long, forgetting to
provide a little more detail here.

When I have requires = $foo, the catalog does compile and $foo does
resolve to Class['a'] or Class['b'] correctly when I look at the debug
output from the Puppet agent (puppet agent -tv --debug).

If I use the anchor method as well ($foo -> Class['a]), it wasn't
installing it in the preferred order as well, but if I use the anchor
method on the Service Type that Class['a'] provides in its service.pp,
then it worked for me.

There seems to be a bit of a terminology gap here.  Class['a'] does not "have" a service.pp in any useful sense of the term.  I suppose you probably mean that module 'a' has a class or defined type "a::service" whose definition resides in modules/a/manifests/service.pp.  The distinction matters, as does, in particular, whether a::service is a class or a defined type.  (In a typical module architecture, such a thing would be a class.)

Moreover, it's unclear what you mean when you say you "use the anchor method on the Service Type [...]."  I can probably guess roughly what you mean, but here, too, the details matter.  We can give better answers if you present code that actually exhibits the problem -- preferrably minimal code that does so.

 

>> This should work:
>>
>> $foo = "a"
>>
>> File["/path/to/file"] { require => Class[$foo] }
>>

This method allowed the catalog to compile as well, but didn't change
any of the ordering issues.

My best guess at this point is that you have a class containment issue.  That is, Puppet is very likely applying the ordering you specify, but that doesn't have the effect you expect because Class['a'] and/or Class['b'] declares other classes that you consider as belonging to 'a' / 'b', but which are not properly contained by 'a' / 'b'.


John

[Jason Wever]

On Tue, Jan 20, 2015 at 9:40 AM, jcbollinger <John.Bo...@stjude.org> wrote:
> There seems to be a bit of a terminology gap here. Class['a'] does not
> "have" a service.pp in any useful sense of the term. I suppose you probably
> mean that module 'a' has a class or defined type "a::service" whose
> definition resides in modules/a/manifests/service.pp. The distinction
> matters, as does, in particular, whether a::service is a class or a defined
> type. (In a typical module architecture, such a thing would be a class.)

Yes, that is correct. Sorry for my lack of proper terminology.

> Moreover, it's unclear what you mean when you say you "use the anchor method
> on the Service Type [...]." I can probably guess roughly what you mean, but
> here, too, the details matter. We can give better answers if you present
> code that actually exhibits the problem -- preferrably minimal code that
> does so.

Point taken.

> My best guess at this point is that you have a class containment issue.
> That is, Puppet is very likely applying the ordering you specify, but that
> doesn't have the effect you expect because Class['a'] and/or Class['b']
> declares other classes that you consider as belonging to 'a' / 'b', but
> which are not properly contained by 'a' / 'b'.

Thanks for the link. This does sound like what is going on. I'll
take a look at the module and see if this will help.

Thanks,
--
Jason Wever