thr3ads.net - Puppet users - [Puppet Users] Problem of ordering with exported files [Aug 2013]

If this information is useful, please help other people find it:
Share via:

François Lafont

2013-Aug-27 06:51 UTC

[Puppet Users] Problem of ordering with exported files

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.

François Lafont

2013-Aug-27 12:39 UTC

head link

[Puppet Users] Re: Problem of ordering with exported files

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

2013-Aug-27 19:23 UTC

head link

[Puppet Users] Re: Problem of ordering with exported files

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

2013-Aug-27 23:47 UTC

head link

Re: [Puppet Users] Re: Problem of ordering with exported files

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

2013-Aug-28 14:53 UTC

head link

Re: [Puppet Users] Re: Problem of ordering with exported files

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

2013-Aug-29 21:59 UTC

head link

Re: [Puppet Users] Re: Problem of ordering with exported files

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

2013-Aug-30 13:20 UTC

head link

Re: [Puppet Users] Re: Problem of ordering with exported files

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.

Puppet users - Aug 2013 - Problem of ordering with exported files

[Puppet Users] Problem of ordering with exported files

[Puppet Users] Re: Problem of ordering with exported files

[Puppet Users] Re: Problem of ordering with exported files

Re: [Puppet Users] Re: Problem of ordering with exported files

Re: [Puppet Users] Re: Problem of ordering with exported files

Re: [Puppet Users] Re: Problem of ordering with exported files

Re: [Puppet Users] Re: Problem of ordering with exported files