FAQ
Hi,

I use Puppet 3.2 (with hiera) on Debian Wheezy and I have
a problem of ordering with exported files.

I have 2 puppet clients :

1) server.mydomain.priv with this yaml:

---
classes:
  - test::server

2) and node.mydomain.priv with this yaml:

---
classes:
  - test::node

Here is my (very simple) "test" module:

---------------------------------------
class test::node {

     @@file { "${::hostname}_exported":
         path => "/usr/local/puppet_host/exported/${::hostname}_exported",
         content => "node\n",
         tag => "exported",
     }

}
---------------------------------------

And

---------------------------------------
class test::server {

     $managed_directories = [
         '/usr/local/puppet_host',
         '/usr/local/puppet_host/exported',
     ]

     file { $managed_directories:
         ensure => directory,
         mode => 750,
         recurse => true,
         force => true,
     }

     file { '/usr/local/puppet_host/list':
         mode => 440,
         content => "List.\n",
     }

     File <<| tag == 'exported' |>> {
         mode => 0644,
     }

     # Ordering
     File[$managed_directories]
       -> File['/usr/local/puppet_host/list']
       -> File <<| tag == 'exported' |>> # <-- exported files at the end !!!
}
---------------------------------------

No problem when I run puppet on node.mydomain.priv. But after,
on server.mydomain.priv, I have this:

root@server:~# puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for server.mydomain.priv
Info: Applying configuration version '1377583717'
Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host]/ensure: created
Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/exported]/ensure: created
Notice: /Stage[main]/Test::Server/File[node_exported]/ensure: defined content as '{md5}449b092c7cda6f1d7d1d5a804ac1bfd3'
Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/list]/ensure: defined content as '{md5}62171c0c9812eb038aa53a42e30a97f8'
Notice: Finished catalog run in 0.08 seconds

In the test::server class, I have forced the exported file to be
created at the end. But, during the puppet run, this is not the case,
and the File[/usr/local/puppet_host/list] resource is realized *after*
the exported file.

Why? Is it normal? Did I forget anything?
How I can force the exported file to be created at the end?
Thanks in advance for your help.

--
Francois Lafont

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • François Lafont at Aug 27, 2013 at 12:39 pm

    Le 27/08/2013 08:51, François Lafont a écrit :

    In the test::server class, I have forced the exported file to be
    created at the end. But, during the puppet run, this is not the case,
    and the File[/usr/local/puppet_host/list] resource is realized *after*
    the exported file.
    I'm wondering if this is not a bug.

    If I just change the *title* of the exported file, the order is correct.

    ---------------------------------------
    class test::node {

         ## @@file { "${::hostname}_exported": <----- I just change the title.
         @@file { "${::hostname}": # <----- The new title
             content => "node\n",
             tag => "exported",
             path => "/usr/local/puppet_host/exported/${::hostname}_exported",

         }

    }
    ---------------------------------------

    Then:

    root@node:~# puppet agent --test
    Info: Retrieving plugin
    Info: Caching catalog for node.mydomain.priv
    Info: Applying configuration version '1377606380'
    Notice: Finished catalog run in 0.02 seconds

    And:

    root@server:~# rm -r /usr/local/puppet_host/; puppet agent --test
    Info: Retrieving plugin
    Info: Caching catalog for server.mydomain.priv
    Info: Applying configuration version '1377606673'
    Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host]/ensure: created
    Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/exported]/ensure: created
    Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host/list]/ensure: defined content as '{md5}62171c0c9812eb038aa53a42e30a97f8'
    Notice: /Stage[main]/Test::Server/File[node]/ensure: defined content as '{md5}449b092c7cda6f1d7d1d5a804ac1bfd3'
    Notice: Finished catalog run in 0.07 seconds

    Here, the exported file is created at the end of the puppet run.
    Is it normal that the order changes just with a modification of the title resource?

    Thanks in advance.

    --
    Francois Lafont

    --
    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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Aug 27, 2013 at 7:23 pm

    On Tuesday, August 27, 2013 1:51:50 AM UTC-5, François Lafont wrote:
    Hi,

    I use Puppet 3.2 (with hiera) on Debian Wheezy and I have
    a problem of ordering with exported files.

    I have 2 puppet clients :

    1) server.mydomain.priv with this yaml:

    ---
    classes:
    - test::server

    2) and node.mydomain.priv with this yaml:

    ---
    classes:
    - test::node

    Here is my (very simple) "test" module:

    ---------------------------------------
    class test::node {

    @@file { "${::hostname}_exported":
    path =>
    "/usr/local/puppet_host/exported/${::hostname}_exported",
    content => "node\n",
    tag => "exported",
    }

    }
    ---------------------------------------

    And

    ---------------------------------------
    class test::server {

    $managed_directories = [
    '/usr/local/puppet_host',
    '/usr/local/puppet_host/exported',
    ]

    file { $managed_directories:
    ensure => directory,
    mode => 750,
    recurse => true,
    force => true,
    }

    file { '/usr/local/puppet_host/list':
    mode => 440,
    content => "List.\n",
    }

    File <<| tag == 'exported' |>> {
    mode => 0644,
    }

    # Ordering
    File[$managed_directories]
    -> File['/usr/local/puppet_host/list']
    -> File <<| tag == 'exported' |>> # <-- exported files at the end
    !!!
    }
    ---------------------------------------

    No problem when I run puppet on node.mydomain.priv. But after,
    on server.mydomain.priv, I have this:

    root@server:~# puppet agent --test
    Info: Retrieving plugin
    Info: Caching catalog for server.mydomain.priv
    Info: Applying configuration version '1377583717'
    Notice: /Stage[main]/Test::Server/File[/usr/local/puppet_host]/ensure:
    created
    Notice:
    /Stage[main]/Test::Server/File[/usr/local/puppet_host/exported]/ensure:
    created
    Notice: /Stage[main]/Test::Server/File[node_exported]/ensure: defined
    content as '{md5}449b092c7cda6f1d7d1d5a804ac1bfd3'
    Notice:
    /Stage[main]/Test::Server/File[/usr/local/puppet_host/list]/ensure: defined
    content as '{md5}62171c0c9812eb038aa53a42e30a97f8'
    Notice: Finished catalog run in 0.08 seconds

    In the test::server class, I have forced the exported file to be
    created at the end. But, during the puppet run, this is not the case,
    and the File[/usr/local/puppet_host/list] resource is realized *after*
    the exported file.

    Why? Is it normal? Did I forget anything?
    How I can force the exported file to be created at the end?
    I don't see anything obviously forgotten or wrong, but there are a few
    strange things:

        1. You collect the same exported File resources twice in the same
        class. I wouldn't have expected that to be a problem, but unusual code is
        more likely to tickle bugs. I suspect that this is indeed where your
        trouble lies.
        2. You seem to be declaring relationships that for the most part
        duplicate those that Puppet can normally be relied upon to create
        automatically ("autodepends"). Specifically, if a file and its parent
        directory are both under management, and no relationship is otherwise
        declared between them, then Puppet will automatically manage the directory
        before the file. Explicitly declaring the same relationships is not an
        error, however.
        3. You are declaring recursive directories without any 'source'
        parameters. That probably does not mean what you think it means, because
        in that case the recursiveness has no effect.
        4. You declare 'force => true', which is only necessary to enable
        clobbering existing directories, but the other parameters don't contain
        anything that could make that needful.
        5. You declare that File['/usr/local/puppet_host/list'] must be applied
        before any of the exported Files tagged 'exported', but that does not
        appear to be needful. Still, that's not erroneous.


    I might write class test::server more like this:

    class test::server {
         file { [ '/usr/local/puppet_host',
                  '/usr/local/puppet_host/exported' ]:
             ensure => directory,
             mode => 750
         }

         file { '/usr/local/puppet_host/list':
             mode => 440,
             content => "List.\n",
         }

         File <<| tag == 'exported' |>> {
             mode => 0644,
         }
    }

    For explicit relationships, either declare them via the 'require' and/or
    'before' metaparameters, or put chain operators between the declarations
    above as needed.


    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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • François Lafont at Aug 27, 2013 at 11:47 pm
    Hello,

    Firstly, thank you John for your answer.
    Le 27/08/2013 21:23, jcbollinger wrote :

    I don't see anything obviously forgotten or wrong, but there are a few
    strange things:
    It's possible. ;-)
    1. You collect the same exported File resources twice in the same
    class.
    Really?

    In fact, I have tried to follow this doc:
    http://docs.puppetlabs.com/learning/ordering.html#chaining-arrows
    where you can see this example:

    ----------------------------------------
    # 1. One declaration.
    file {'/tmp/test1':
       ensure => present,
       content => "Hi.",
    }

    # 2. Another one.
    notify {'after':
       message => '/tmp/test1 has already been synced.',
    }

    # 3. Ordering.
    File['/tmp/test1'] -> Notify['after']
    ----------------------------------------

    And the same page tells:

    "Chaining arrows can take several things as their
    operands: this example uses resource references, but they can also take
    resource declarations and resource collectors."

    As a result, I have deduced that this code below was correct *and* not redundant:

    ----------------------------------------
    # 1. One declaration.
    file { '/usr/local/puppet_host/list':
         mode => 440,
         content => "List.\n",
    }

    # 2. Another one.
    File <<| tag == 'exported' |>> {
         mode => 0644,
    }

    # 3. Ordering.
    File['/usr/local/puppet_host/list'] -> File <<| tag == 'exported' |>>
    ----------------------------------------

    Am I wrong?

    * file { '/tmp/a': } is a resource declaration
    * File['/tmp/a'] is a resource reference (for the chaining by example)
       but not a declaration

    And I thought that File <<| tag == 'exported' |>> was a resource reference
    but not a resource declaration. In fact, it seems to me that a resources
    collector is a resources declaration *and* a resource reference. This
    point is not very clear for me...

    If I understand, the code above is correct but redundant, is'nt it?
    And the correct and not redundant way with chaning is:

    ----------------------------------------
    file { '/usr/local/puppet_host/list':
         mode => 440,
         content => "List.\n",
    }

    ->

    File <<| tag == 'exported' |>> {
         mode => 0644,
    }
    ----------------------------------------

    Is that correct?

    Is it possible to separate declaration and after chaining like in the first
    example? Perhaps it's impossible with exported resources...

    I wouldn't have expected that to be a problem, but unusual code is
    more likely to tickle bugs.
    Yes and I don't like to tickle bugs. ;-)
    This is why I want to follow the good practices (when it will be clear in
    my spirit).
    I suspect that this is indeed where your
    trouble lies.
    It's possible. I think It's will be more clear at the end of this
    post. ;-)
    2. You seem to be declaring relationships that for the most part
    duplicate those that Puppet can normally be relied upon to create
    automatically ("autodepends"). Specifically, if a file and its parent
    directory are both under management, and no relationship is otherwise
    declared between them, then Puppet will automatically manage the directory
    before the file. Explicitly declaring the same relationships is not an
    error, however.
    Yes, I understand that. But sometimes we want to force ordering.
    3. You are declaring recursive directories without any 'source'
    parameters. That probably does not mean what you think it means, because
    in that case the recursiveness has no effect.
    4. You declare 'force => true', which is only necessary to enable
    clobbering existing directories, but the other parameters don't contain
    anything that could make that needful.
    Sorry it's my fault, I have forgotten 'purge => true' in my code. So, in fact
    it's:

         file { $managed_directories:
             ensure => directory,
             mode => 750,
             purge => true,
             recurse => true,
             force => true,
         }

    I hope it's consistent now.
    5. You declare that File['/usr/local/puppet_host/list'] must be applied
    before any of the exported Files tagged 'exported', but that does not
    appear to be needful.
    Yes, because my example is an "MCE" (Minimal and Complete Example that shows my
    problem). Indeed, in this example this is'nt needful but in my real puppet code
    this is needful, I want to create the exported files in an precise moment (and
    my reasons are valid to my mind but irrelevant in this post).
    I might write class test::server more like this:

    class test::server {
    file { [ '/usr/local/puppet_host',
    '/usr/local/puppet_host/exported' ]:
    ensure => directory,
    mode => 750
    }

    file { '/usr/local/puppet_host/list':
    mode => 440,
    content => "List.\n",
    }

    File <<| tag == 'exported' |>> {
    mode => 0644,
    }
    }

    For explicit relationships, either declare them via the 'require' and/or
    'before' metaparameters,
    I don't know why, but I prefer the chaining. Perhaps because I found it's
    more explicit and visual (this is a personnal opinion).
    or put chain operators between the declarations
    above as needed.
    Ok, something like that if I understand:

    class test::server {

         # ...
         file { '/usr/local/puppet_host/list':
             mode => 440,
             content => "List.\n",
         }

         ->

         File <<| tag == 'exported' |>> {
             mode => 0644,
         }

    }

    Is it possible to separate declaration and ordering?

    In any case, indeed, with the code above, the order is correct,
    exactly as I want. But I want to separate declarations first and
    then the chaining I haven't the good order.

    Thank a lot for your help John.

    --
    Francois Lafont

    --
    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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Aug 28, 2013 at 2:53 pm

    On Tuesday, August 27, 2013 6:47:41 PM UTC-5, François Lafont wrote:
    Hello,

    Firstly, thank you John for your answer.
    Le 27/08/2013 21:23, jcbollinger wrote :

    I don't see anything obviously forgotten or wrong, but there are a few
    strange things:
    It's possible. ;-)
    1. You collect the same exported File resources twice in the same
    class.
    Really?

    Yes.


    In fact, I have tried to follow this doc:
    http://docs.puppetlabs.com/learning/ordering.html#chaining-arrows
    where you can see this example:

    ----------------------------------------
    # 1. One declaration.
    file {'/tmp/test1':
    ensure => present,
    content => "Hi.",
    }

    # 2. Another one.
    notify {'after':
    message => '/tmp/test1 has already been synced.',
    }

    # 3. Ordering.
    File['/tmp/test1'] -> Notify['after']
    ----------------------------------------

    And the same page tells:

    "Chaining arrows can take several things as their
    operands: this example uses resource references, but they can also take
    resource declarations and resource collectors."

    As a result, I have deduced that this code below was correct *and* not
    redundant:

    ----------------------------------------
    # 1. One declaration.
    file { '/usr/local/puppet_host/list':
    mode => 440,
    content => "List.\n",
    }

    # 2. Another one.
    File <<| tag == 'exported' |>> {
    mode => 0644,
    }

    # 3. Ordering.
    File['/usr/local/puppet_host/list'] -> File <<| tag == 'exported' |>>
    ----------------------------------------

    Am I wrong?

    Yes. The code is at least redundant, in that both appearances of

    File <<| tag == 'exported' |>>

    specify the inclusion of the matching resources in the target node's
    catalog, regardless of the fact that they appear in contexts that carry
    distinct additional implications.

    In fact, when you bring resource property overrides into the picture as you
    have done, multiple collections of the same resources could be construed as
    conflicting.


    * file { '/tmp/a': } is a resource declaration
    * File['/tmp/a'] is a resource reference (for the chaining by example)
    but not a declaration

    And I thought that File <<| tag == 'exported' |>> was a resource reference
    but not a resource declaration. In fact, it seems to me that a resources
    collector is a resources declaration *and* a resource reference. This
    point is not very clear for me...

    That is understandable, as the syntax is a bit magic. Collectors are not
    declarations of individual resources, but they *are* declarations of *
    collections* of zero or more individual resources declared elsewhere. The
    most fundamental effect of a collection declaration is to ensure that the
    collected member resources are included in the target node's catalog.

    Above and beyond that, they can be used to additionally override parameters
    of member resources and in chaining expressions. Those are also
    capabilities of resource references (but also of individual resource
    declarations, more or less). And multiple declarations of the same
    collection are not construed as erroneous, though I'm suggesting that they
    might not work as you would expect in that case.


    If I understand, the code above is correct but redundant, is'nt it?
    And the correct and not redundant way with chaning is:

    ----------------------------------------
    file { '/usr/local/puppet_host/list':
    mode => 440,
    content => "List.\n",
    }

    ->

    File <<| tag == 'exported' |>> {
    mode => 0644,
    }
    ----------------------------------------

    Is that correct?

    That is certainly non-redundant, and it looks correct to me.

    Alternatively, you could accomplish the same thing by using the 'require'
    metaparameter instead of the chaining operator:

       file { '/usr/local/puppet_host/list':
         mode => 440,
         content => "List.\n",
       }

       File <<| tag == 'exported' |>> {
         mode => 0644,
         require => File['/usr/local/puppet_host/list']
       }

    in which case you could separate the two stanzas, even into different
    classes.

    Is it possible to separate declaration and after chaining like in the
    first
    example? Perhaps it's impossible with exported resources...
    That's the thing. The syntax seems to support it, just as you originally
    wrote, and I would expect your original code to do what you wanted. I
    cannot explain why it doesn't; I'm just trying to help you find a
    workaround.


    I wouldn't have expected that to be a problem, but unusual code is
    more likely to tickle bugs.
    Yes and I don't like to tickle bugs. ;-)
    This is why I want to follow the good practices (when it will be clear in
    my spirit).
    I suspect that this is indeed where your
    trouble lies.
    It's possible. I think It's will be more clear at the end of this
    post. ;-)
      [...]
    3. You are declaring recursive directories without any 'source'
    parameters. That probably does not mean what you think it means, because
    in that case the recursiveness has no effect.
    4. You declare 'force => true', which is only necessary to enable
    clobbering existing directories, but the other parameters don't contain
    anything that could make that needful.
    Sorry it's my fault, I have forgotten 'purge => true' in my code. So, in
    fact
    it's:

    file { $managed_directories:
    ensure => directory,
    mode => 750,
    purge => true,
    recurse => true,
    force => true,
    }

    I hope it's consistent now.

    The 'force' makes sense then, but I think the 'recurse' will still be
    without any effect. That is, I don't think it will cause the purge to
    descend into managed subdirectories. Perhaps I am mistaken about that,
    though.


    5. You declare that File['/usr/local/puppet_host/list'] must be applied
    before any of the exported Files tagged 'exported', but that does not
    appear to be needful.
    Yes, because my example is an "MCE" (Minimal and Complete Example that
    shows my
    problem).


    Fair enough.



    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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • François Lafont at Aug 29, 2013 at 9:59 pm

    Le 28/08/2013 16:53, jcbollinger wrote :

    As a result, I have deduced that this code below was correct *and* not
    redundant:

    ----------------------------------------
    # 1. One declaration.
    file { '/usr/local/puppet_host/list':
    mode => 440,
    content => "List.\n",
    }

    # 2. Another one.
    File <<| tag == 'exported' |>> {
    mode => 0644,
    }

    # 3. Ordering.
    File['/usr/local/puppet_host/list'] -> File <<| tag == 'exported' |>>
    ----------------------------------------

    Am I wrong?

    Yes. The code is at least redundant, in that both appearances of

    File <<| tag == 'exported' |>>

    specify the inclusion of the matching resources in the target node's
    catalog, regardless of the fact that they appear in contexts that carry
    distinct additional implications.
    Ok, so if I follow your logic, this simple code below is correct and
    redundant too, isn't it? (and the rendundancy is not a problem)

    ----------------------------------------
    # 1. One declaration.
    file {'/tmp/test1':
       ensure => present,
       content => "Hi.",
    }

    # 2. Another one.
    notify {'after':
       message => '/tmp/test1 has already been synced.',
    }

    # 3. Ordering.
    File['/tmp/test1'] -> Notify['after']
    ----------------------------------------
    If I understand, the code above is correct but redundant, is'nt it?
    And the correct and not redundant way with chaning is:

    ----------------------------------------
    file { '/usr/local/puppet_host/list':
    mode => 440,
    content => "List.\n",
    }

    ->

    File <<| tag == 'exported' |>> {
    mode => 0644,
    }
    ----------------------------------------

    Is that correct?

    That is certainly non-redundant, and it looks correct to me.
    [...]
    Is it possible to separate declaration and after chaining like in the
    first
    example? Perhaps it's impossible with exported resources...
    That's the thing. The syntax seems to support it, just as you originally
    wrote, and I would expect your original code to do what you wanted.
    We agree. ;-)
    I cannot explain why it doesn't;
    Me too. Don't you think that it can be interpreted as a little bug? (or
    just a inconsistency?)

    It's very curious, if I just change the title of the exported files,
    then the order is as we expect (I give an example in my message #2).
    I'm just trying to help you find a workaround.
    You don't try, you succeed in doing so and I thank you for that. ;-)

    --
    Francois Lafont

    --
    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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Aug 30, 2013 at 1:20 pm

    On Thursday, August 29, 2013 4:59:16 PM UTC-5, François Lafont wrote:
    Le 28/08/2013 16:53, jcbollinger wrote :

    As a result, I have deduced that this code below was correct *and* not
    redundant:

    ----------------------------------------
    # 1. One declaration.
    file { '/usr/local/puppet_host/list':
    mode => 440,
    content => "List.\n",
    }

    # 2. Another one.
    File <<| tag == 'exported' |>> {
    mode => 0644,
    }

    # 3. Ordering.
    File['/usr/local/puppet_host/list'] -> File <<| tag == 'exported' |>>
    ----------------------------------------

    Am I wrong?

    Yes. The code is at least redundant, in that both appearances of

    File <<| tag == 'exported' |>>

    specify the inclusion of the matching resources in the target node's
    catalog, regardless of the fact that they appear in contexts that carry
    distinct additional implications.
    Ok, so if I follow your logic, this simple code below is correct and
    redundant too, isn't it? (and the rendundancy is not a problem)

    ----------------------------------------
    # 1. One declaration.
    file {'/tmp/test1':
    ensure => present,
    content => "Hi.",
    }

    # 2. Another one.
    notify {'after':
    message => '/tmp/test1 has already been synced.',
    }

    # 3. Ordering.
    File['/tmp/test1'] -> Notify['after']
    ----------------------------------------
    No, that is not redundant. Resource references do not direct Puppet to
    include the referenced resources in the target node's catalog. Instead,
    they depend on those resources being declared by other means, else catalog
    compilation will fail.

    Collectors are different, partly because they combine two distinct
    functions:

        1. to realize virtual resources or import exported resources (depending
        on the form of the collector), and
        2. to serve essentially as a reference to the whole group of collected
        resources

    It is with respect to the former that collecting the same resources
    multiple times is redundant, and ordinary resource references do not serve
    that purpose.

    Nevertheless, I'm really just trying to rationalize the odd behavior you
    observed. I would not have expected your original code to exhibit the
    problems it did, and I think it would be better for Puppet to behave as you
    expected in this regard.

    Me too. Don't you think that it can be interpreted as a little bug? (or
    just a inconsistency?)

    Yes, I think it would be reasonable to interpret the behavior as buggy. I
    think you would be justified in filing a bug ticket with PuppetLabs over
    this. There might even be one already; I didn't check.


    It's very curious, if I just change the title of the exported files,
    then the order is as we expect (I give an example in my message #2).
    I think that's just luck. Your original code clearly does not result in
    the desired ordering relationship being included in the node's catalog.
    Where relationships do not constrain the relative order of two resources,
    Puppet is free to apply them in either order. In practice, it uses an
    order that is essentially unpredictable, but that remains stable *provided
    that the affected resources do not change*. Changing resource titles,
    however, can result in a different order of application.


    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.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedAug 27, '13 at 6:51a
activeAug 30, '13 at 1:20p
posts7
users2
websitepuppetlabs.com

2 users in discussion

François Lafont: 4 posts Jcbollinger: 3 posts

People

Translate

site design / logo © 2022 Grokbase