Thank you so much John, for taking time and explaining in detail. This
really helps new learner like me. :)
Thanks again.
Amogh
On Fri, Oct 31, 2014 at 8:22 AM, jcbollinger <john.bollin...@stjude.org>
wrote:
>
>
> On Thursday, October 30, 2014 12:46:07 PM UTC-5, amogh patel wrote:
>>
>> Thanks, John. It did help. I was wondering if we can somehow use an array
>> of these hashes so that we don't have to use require.
>>
>>
> There are no hashes in my example. In particular, resource declarations
> are not hashes, and do not (generally) contain hashes. The only hashes
> discussed in this thread so far are your $fs_hash and its contents.
>
> You can avoid using 'require' by using chaining arrows instead. For
> example,
>
> base::fsdef { '/dev/sdb1': mountpoint => '/data/01' }
> -> base::fsdef { '/dev/sdc1': mountpoint => '/data/02' }
> -> base::fsdef { '/dev/sdd1': mountpoint => '/data/03' }
> -> base::fsdef { '/dev/sde1': mountpoint => '/data/04' }
> -> base::fsdef { '/dev/sdf1': mountpoint => '/data/05' }
> -> base::fsdef { '/dev/sdg1': mountpoint => '/data/06' }
> -> base::fsdef { '/dev/sdh1': mountpoint => '/data/07' }
> -> base::fsdef { '/dev/sdi1': mountpoint => '/data/08' }
> -> base::fsdef { '/dev/sdj1': mountpoint => '/data/09' }
> -> base::fsdef { '/dev/sdk1': mountpoint => '/data/10' }
>
> That is 100% equivalent to the alternative using the 'require'
> metaparameter. You can even mix and match. You can also add relationships
> after the fact by applying chaining arrows to resource references:
>
> file { '/tmp/after': ensure => 'file' }
> file { '/tmp/before': ensure => 'file' }
>
> # this may appear anywhere in the manifest set:
> File['/tmp/before'] -> File['/tmp/after']
>
> If your point in wanting to avoid 'require' is that you want an attempt to
> be made to perform each mount, even if previously-listed ones fail, then we
> come back around to my previous opening question: why? Why does the order
> in which the mounts are applied matter?
>
> Anyway, the Puppet documentation contains a full description of factors
> affecting resource application order
> <https://docs.puppetlabs.com/learning/ordering.html>. You should read
> and understand the whole thing.
>
> I note in advance that you will find among the docs reference to Puppet's
> 'ordering' configuration parameter. You may like the sound of it, but you
> shouldn't. If you have bona fide requirements for the order in which
> resources are applied, then you should declare those requirements
> explicitly in your manifests (as the docs also say).
>
>
> John
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/LAfBVAH-D1g/unsubscribe.
> To unsubscribe from this group and all its topics, 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/b8c3b792-1af2-4649-a98e-92fd7b65dd1b%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/b8c3b792-1af2-4649-a98e-92fd7b65dd1b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAJppLho54HHUJGaDvoPo5Wf7Ba6H_v9v%3D%2B7B0ye%2BOBiFOL3UKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
