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 <[email protected]> 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 > [email protected]. > 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 [email protected]. 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.
